[MPlayer-dev-eng] [PATCH] A new ASS renderer
Xidorn Quan
quanxunzhen at gmail.com
Sun Sep 23 18:31:54 CEST 2012
On Sun, Sep 23, 2012 at 11:15 PM, wm4 <nfxjfg at googlemail.com> 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.
>
Partially true. If subtitle is changed every frame, most time is
spent in libass, but if not, more time may need to be spent in
rendering subimages over and over again.
More information about the MPlayer-dev-eng
mailing list