[MPlayer-dev-eng] [PATCH] A new ASS renderer

[Reimar Döffinger]

On Sun, Sep 23, 2012 at 04:01:27PM +0200, wm4 wrote:
> On Sun, 23 Sep 2012 15:30:54 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > I disagree. Only libass can e.g. look ahead and pool glyphs by how
> > often they will be used in the future just as an example.
> > It also can speed up libass itself by reducing allocations/frees if it
> > pools the glyphs.
> 
> libass does cache glyphs. Actually, you could say libass is one big
> cache: libass parses/layouts/renders subtitle events every frame again.
> But it's fast, because expensive operations (rendering fonts to
> bitmaps) are cached.

It caches to avoid rendering the glyphs, it does not cache them to
minimize processing or even cache usage.
The latter requires that glyphs that are used together are grouped
together.

> But I think in conclusion, all of this is relatively worthless. Even
> with very complicated subtitles, the time spent in the freetype
> renderer is much higher than that in vf_ass or on the GPU.

You missed the point. The point is not to speed up the freetype
rendering but to speed up processing: by getting the data in nice
big blocks that are easy to process with SIMD instructions and/or
require few texture uploads without possibly processing data of which
you don't actually need 90% for the current frame.
The when running on the GPU, the alpha blending does not take any
relevant amount of time, what breaks the GPU render's neck is when
it has to upload 10000 2x2 images that are then stored in 10000
different textures.

> > Only libass can e.g. look ahead
> 
> You could easily request a frame from the future from libass, provided
> libass has received all necessary subtitle packets. The rendering
> interface takes a time value.

That is useless, since what you need is to have all glyphs that are used
repeatedly in future frames are stored together in a shared memory area
(and preferably without introducing yet another memcpy),
whereas all that are used only a few times are not there but still
grouped together so they can be processed in one go.