[MPlayer-dev-eng] [PATCH] libass improvements and fixes

[Uoti Urpala]

On Sat, 2009-02-07 at 04:27 +0100, Grigori G wrote:
> Evgeniy Stepanov wrote:
> > It's not a fix, it's a regression. It adds a little transparency between the 
> > border and the actual glyph. It happens because in current implementation 
> > bitmaps are blitted one by one to a video frame. Suppose for some pixel 
> > opacity(glyph) = opacity(border) = 1/2. After blitting first bitmap we have 1/2 
> > glyph color and 1/2 background color. After blitting the second one we have 
> > 1/4 glyph color, 1/4 background color and 1/2 border color. That looks ugly.
> >
> 
> I just noticed the change in svn (rev. 20890) that introduced this fix
> I consider a bug. I actually came up with the regression myself.
> 
> I still think that the "fix" you introduced breaks aa sometimes (esp. 
> against white background) -- please compare toradora-old.png and 
> toradora-new.png at
> http://greg.geekmind.org/mplayer/ (the gray text in the top left)
> The antialiasing on toradora-old.png is very ugly and that's with your
> fix. Without it, e.g. with my regression it looks a lot better. OTOH the 
> code I propose makes antialiasing a bit uglier sometimes with different 
> color combinations.
> 
> How about a compromise, e.g.
> 	o[x] = (c_o > c_g) ? c_o - c_g/2 : 0;
> which looks okay, but not great, with any color combination. Yeah, I'm 
> serious. :)

It's not just antialiasing and the colors used in the subtitles that
matter. The problem is that you make the glyph+border combination _as a
whole_ transparent even where it should be opaque. The error doesn't
show in your example because everything is a shade of gray and you can't
see the parts that would contain completely wrong hues. But if you for
example had (opaque) subtitle and border in shades of gray on a red
background then there would be red at the boundary between the glyph and
border - completely wrong.