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

[Reimar Döffinger]

On Sun, Sep 23, 2012 at 05:15:42PM +0200, wm4 wrote:
> On Sun, 23 Sep 2012 16:37:20 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > I am afraid that will depend on a lot of things.
> > For example how fast the driver is at creating a new texture vs.
> > just updating one.
> > Some drivers for example also have huge issues with memory
> > fragmentation when allocating and freeing huge textures of different
> > sizes all the time.
> > Then there's also a question whether it's a subtitle where things
> > change all the time or one where 90% stays the same and a small thing
> > changes (in which case I suspect your approach would waste a good bit
> > of memory bandwidth? Here integrated vs. dedicated GPU can make a lot
> > of difference if that's a problem).
> > Lastly, if the driver decides to use a host-memory backing texture,
> > the glTexSubImage calls can be almost as fast as a memcpy, but that
> > relies heavily on driver details.
> 
> The number of people who tested my changes is probably rather low, but
> I haven't heard of any negative reports yet. It seems to be an overall
> improvement.
> 
> I was thinking a relatively easy way to improve upon this would be
> making libass export cache info (like assigning each sub-image a unique
> ID), and then using a ringbuffer of textures: on each frame, you'd
> upload a frame's new sub-images to a texture. Images that are already
> uploaded to an old texture could be reused. If the current texture is
> full, go to the next one in the ringbuffer, flush all old images, and
> reupload all what's needed.
> 
> Just a random idea. Didn't bother with it, because again, it would
> probably be a useless optimization.
> 
> In general, with libass, you have two types of frames: 1. practically
> static and rather small, and 2. *Everything* changes, can happen with
> all sizes. What's the often cited case where only a "small" thing
> changes, but there's a significant amount of other images that are
> still static? Or in other words, a case where a clever caching scheme
> would actually help a lot.
> 
> And again, most time is spent in libass, not uploading or rendering the
> sub-images. Or does anyone have different experiences? I'd like to hear
> of it. Maybe I'm missing something.

No, I don't think you do. Which is the reason why I never optimized
the -vo gl version more: it seemed fast enough at that point.
So I am also kind of curious if there was a specific reason why you
implemented your variant for -vo gl? (you mentioned OS X I think)
I just don't particularly like that it has some known pathological cases
where it will behave vastly worse than it could (and also vastly worse
than software rendering).