[MPlayer-dev-eng] [PATCH] Re : Re : Direct3D vo performance increase

[Reimar Döffinger]

On Mon, Nov 24, 2008 at 09:14:24PM +0000, Jim Hauxwell wrote:
> I've updated to the latest svn converted my OSD patch to new framework.
> 
> >> Please don't get angry with me, but I seriously doubt that patch
> >> provides any useful starting point. Problems it has:
> >> 1) OSD is drawn with one frame delay
> 
> OSD is drawn at the same point the gl renderer draws it, its beyond the
> scope of the callbacks to fix this.  You would probably have to delve
> into sub.c to get this sorted out.

No it is not. First the frame is rendered in draw_image, then its OSD is
rendered in draw_osd, but only to the texture and on the draw_frame for
the next frame that texture is overlayed.
vo_gl in contrast draws the OSD immediately.

> >> 2) OSD is rendered in software first and then once more in hardware
> 
> Again does the same as the gl renderer.

You use vo_draw_alpha_rgb32 which does alpha blending and more in
software. vo_gl does not.

> >> 3) no alpha-blending is done at all
> 
> The base layer provided no alpha channel, so there wasn't much point
> turning it on.  This is my next thing to look at.  The patch to enable
> the alpha is very small, but alpha bending has a performance penalty
> which is why its not on at the moment.

What do you mean by "base layer"?
Also, for machines where alpha blending is too slow it is possible to
define FAST_OSD, which works without alpha blending.

> >> 4) the OSD is completely redrawn even if it did not change at all
> 
> This is not true, it gets called once when placed on the screen and once
> when taken off, so should save on CPU compared to a render which dumps
> directly onto the video.

Huh? You call vo_draw_text on each call to draw_osd, without checking
vo_osd_changed, so yes you do completely redraw (as in calling
vo_draw_alpha_rgb32 and the texture transfer functions) the OSD each
frame.

Greetings,
Reimar Döffinger