[MPlayer-dev-eng] Direct rendering feature request

[Jiri Svoboda]

> 
> Hi,
> 
> > Hi,
> > is there any or _could_ be there a function call to notify 
> vo_driver, 
> > when frame decoding is finished (in direct rendering)?
> 
> yes. flip_page() is called when decoding is finished.

Yes it's true but I need something before drawing osd not after.
Just to know when image is completely decoded and I can manipulate with
it.

> 
> > I have to lock buffer in get_image() and need to know when 
> to unlock 
> > it. Could be a draw_osd used for this? I'm not sure if it is called 
> > in/after each frame.
> no, draw_osd is optional and isn't called when osd is disabled
> 
> > My desired scheme for frame disp:
> > - get_image called -> buffer locked for decoder access
> > - __decode_complete__ called -> buffer is unlocked, (stretch)blit 
> > initiated to scale and transfer from buffer to offscreen 
> video memory 
> > (done preferably by hw)-->> this is missing
> > - draw_osd/alpha -> osd is drawn in offscreen video memory (eg. osd 
> > and subtitles are using whole screen not just film area)
> > - flip -> flip is performed (switched video memory buffers)
> >  
> > As it works today (in vo_directfb)
> > - get_image called -> buffer locked for decoder access
> > - draw_osd/alpha ->buffer is unlocked, osd is drawn in buffer (has 
> > some side effect when bufffer is static)
> > - flip -> (stretch)blit initiated to scale and transfer 
> from buffer to 
> > screen
> 
> hmm. is directfb able to transfer image from system ram to 
> video ram without using cpu ? (i mean between draw_osd and flip_page)

No, but is able to use hw stretch blit and load image in background to
videomemory (directfb lib itself is using threads).

> anyway it's easy to add a new control() similar to get_image 
> to notify driver when done (like image_finished).

This would be best solution.

> 
> btw. it's possible (i'm trying to avoid but happens sometimes) that
> get_image() is called but no real rendering (broken frame 
> etc) so no draw_osd and flip_page call follows it.
> 
> so, the finish_image control() call should also tell eth 
> driver if it actually did something (blit) or not (just unlock)

That sounds interesting - could save a lot of processor time.

There is another issue. If I have static buffer, then if I will render
osd into it, osd will be visible not until next frame, but until decoder
overwrites place with osd and this could be a couple frames later ->
artefact from osd. I think this also happens to vo_mga if You decrease
nuber of buffers to 1 -> buffer becomes static ...
Yes I can report that buffer is not static, but this will produce some
unnecesarry traffic.
This is reason why I wont to blit before drawing osd (when the frame is
decoded) - to keep buffer untouched. I see no reson to add another new
software buffer - it's worse than disabling direct rendering.

				JS