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

[Evgeniy Stepanov]

On Wednesday 18 February 2009 08:08:42 Grigori G wrote:
> Hi,
>
> here's some more libass-related hackery. This time I've split up
> everything into tiny pieces. The patches are supplied in the format as
> output by git's format-patch, I hope that is okay.
>
> Now, on to the patches.
>
> * 0001-Ignore-PlayResX-Y-aspect-ratio-for-font-aspect-ratio.patch
> vsfilter, perian, aegisub, et al ignore the PlayResX/PlayResY aspect
> ratio when scaling fonts. This replicates the behaviour.
>
> * 0002-Allow-shadow-without-border.patch
> libass always set a border of 1.0 when a shadow was used. Maybe there's
> a reason for that, but I don't know. I do know of typesets which use
> shadows without borders, though.

ok

> * 0003-Fix-memory-leak-in-blur-handling.patch
> The \blur patch introduced a memory leak, as the memory that is newly
> allocated after blur size changes isn't freed. Now realloc is used
> instead. In addition, the blur size scale is in line with vsfilter.

ok

> * 0004-Fix-warnings.patch
> This silents two rather harmless gcc warnings.

ok

> * 0005-Hack-use-a-compromise-to-force-somewhat-reasonable.patch
> This is the "compromise" hack for the anti-aliasing "fix" I had in the
> last patch already. This might be just a hack, "wrong" and whatever, but
> it still makes the area where glyph and outline overlap a bit at least
> decent looking in all cases (which I tested).

Well, the current behavoir is not much better, and is also a hack. I'll try to 
look for a sample were you variant looks uglier then mine.

> * 0006-Support-one-of-these-braindead-vsfilter-special-case.patch
> vsfilter has very stupid behaviour in case PlayResX/Y aren't specified.
> As stupid as this may be, since vsfilter is more or less the reference
> implementation, it makes sense to emulate it.

Are you sure? Just 1280x1024? What about 1024x768? Look very suspicious :)

> * 0007-Parse-integers-as-doubles-and-then-convert-to-the-ne.patch
> Parse all integers as doubles first and later convert them to the
> nearest integer. This is the much requested "decimal point" support.

ok

> * 0008-Round-shadow-displacement-to-nearest-int.patch
> There's not much to say about it.

Why change the variable type to double, assign it an integer value, and round 
it back later?

> * 0009-Add-simple-blur-with-1-2-1-for-be.patch
> Use a kernel blur with [[1,2,1], [1,2,1], [1,2,1]] matrix for \be. This
> is the same filter used by vsfilter and also a bit faster than the
> gaussian blur.

some other day )

> * 0010-Add-support-for-compositing-of-overlapping-glyph-bor.patch
> This is very experimental, comments appreciated. :)
> Overlapping glyphs, especially outlines, can look very ugly, in case
> they are translucent -- the luminance just adds up!
> This patch adds a pass after the final rendering, where the last two
> bitmaps, if translucent and overlapping, are composited together, e.g.
> for each pixel the maximum value of both bitmaps is used.
> See http://greg.geekmind.org/mplayer/comp.png for a comparison.

Seems fine.

Did you think of rendering the whole line of text (or just chains of 
overlapping bitmaps) into a larger multicolor bitmap? It would solve this 
problem, the problem patch 0005 is aimed at, and will probably improve 
vo_gl/vo_vdpau performance (at least they won't need to join smaller bitmaps 
into large textures). Of course, this is a lot of work.

> * 0011-Scale-shadow-displacement-and-blur-size-like-border.patch
> There's not much to say about it.

Why not scale \be as well?

> * 0012-Correctly-re-initialize-glyph_info_t.patch
> It seems like a glyph_info isn't correctly re-initialized after each
> event. This leads to minor quirks with positioning in at least one case
> (gg's Maria+Holic, Episode 03, 09:06)
> This patch memsets the whole glyph_info instead of only setting certain
> fields to 0.

ok