Hello, I prefer to move all OSD questions/answers in this thread, because we're over with D3D's performance for time being. First of all - Jim, thanks for updating to the latest SVN version and posting patches relative to it - it saves us all :) Let me ask some questions: 1. Drawing on the next frame is fixed easily I think. I'm sure Jim will do it right. 2. What bothers me more is this:
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.
I will look into this.
Hmmm, I have 2 questions: Why are all other drivers I looked into (like vo_directx.c) using vo_draw_alpha_xxxxx? This is supposed to be "software rendering", right Reimar? I mean - you give a texture of some size to the functions and tell in its colorspace and it draws the OSD for you? Additionally as I see the vo_draw_alpha_xxxxx has MMX/SSE/whatever optimizations and they are used when supported. What would be the "hardware" rendering? I can't really understand what is vo_gl.c doing different... vo_gl calls vo_draw_text() with a parameter "create_osd_texture". Inside "create_osd_texture" you seem to "walk" through every OSD "part" and what... generate texture for each one? Or better - vo_draw_text() calls "create_osd_texture" for every OSD element and "create_osd_texture" creates texture for it and places it somewhere, so finally everything gets "blended" on the backbuffer? Please excuse my prehistoric understanding about everything - my day job is writing software for network adapters :) :) :) Are those things explained somewhere, so you can spare your words explaining what's happening? I'm ready to read literature about it... The second question: why do you use vo_draw_alpha_rgb32? Because you create a texture with the same format as the backbuffer? This means that you DON'T "blend" the OSD with the movie's original offscreen surface and then StretchRect it on the backbuffer, but you render the OSD on a texture with the same format as the backbuffer and blend it independent from the offscreen surface of the movie? BTW, I committed a patch for enabling BGR32/16/15 a few hours ago, but this is related to the format of the offscreen surface. Another question: Why does vo_directx.c have support for: vo_draw_alpha_yv12 vo_draw_alpha_yuy2 vo_draw_alpha_rgb15 .... and so on? I think that it does blend the OSD in the equivalent of the offscreen movie source surface or just when using Overlays, the backbuffer itself is equal to the movie's source format and you have to render the OSD in YV12, YUY2 or whatever your movie uses...
Sorry, I misunderstood. It redraws for each frame whilst it is on. I'll fix this.
Does it mean that you must render the OSD in a texture on the first requested frame and just blend it until OSD is on (and haven't changed), so you don't render the OSD without need to do so on every frame (and use the already rendered instead)? I'm sorry for my dumb questions. I'm trying to understand what's happening in the driver I originally wrote and only a week later don't understand anything :D