[MPlayer-users] ssa/ass rendering uses lots of cpu with -vo gl

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2011.01.23 at 20:21:42 +0100, Reimar Döffinger wrote next:

> > for each EOSD image element
> >   find some room for it in one of the textures
> >   copy the bitmap to a memory buffer associated to that texture
> > upload the necessary parts of the memory buffers
> > 
> > Or maybe you already tried that.
> 
> Yes, I meant to say that I tried exactly that, and depending on
> how exactly I did it it (MapBuffer vs. BufferSubData) it was the
> same speed or slower. That's why I blame the driver.
> There are other things that could be tried, but it tends to be quite a bit
> of effort and not that likely to help.
> For this specific case, checking for each part seperately whether
> it was actually changed would help.
> In general it could help for libass to merge non-overlapping glyphs,
> but to a degree these all optimize only some special-cases.

Is it some unvoidable nature of libass rendering that one has to upload
glyphs many times, one by one to the video card? Or you want to say that
merely trying to render glyphs one by one into texture that's yet to be
uploaded causes slowdown already?

Could it be possible to "compact" all the glyphs into yet to be uploaded
texture as a mere image, without using opengl texture functions loading
texture into vram? So to say, "-vf ass" like rendering into transparent
high resolution texture, which is then layered on the main video texture
in one pass? Or it's too complicated..

(I know i'm a bit shooting at random here, sorry :). By the way I'm
using open source radeon driver, even though it lacks behind fglrx in
performance greatly, it has much less issues and problems, I'd rather
use this "slow" driver than go back to fglrx one)

-- 

Vladimir