[Libva] vaPutSurface blend with UI controls

[Gwenole Beauchesne]

Hi,

On Mon, 25 Jan 2010, Yuan, Shengquan wrote:

> 1) vaPutSurface render to a pixmap, then use GLX_TFP/GL to blend
> pros: no new interface is needed
> cons: not all players support GL. for every frame, need additional
> blit (video->pixmap, pixmap->drawable)

Actually, the GLX/TFP approach is indeed suboptimal. We really need a 
specific VA/GLX API and proper driver support. On the AMD side, we can 
transfer a surface to GL texture quite efficiently.

I think it wouldn't be difficult to implement this hook right into the psb 
driver and thus avoiding the TFP indirection.

> 2) use VA subpicture interface: put UI controls to subpicture, then
> blend with surface
> pros: also no new interface is needed
> cons: it may be a burden for players to load UI controls as VA
> subpicture. I am not sure how player response the event if the control
> is pushed.

I have implemented VA subpicture in MPlayer. I think this is the most 
efficient approach as this handles RGBA surfaces directly. It's not a 
problem for events since this is not a child window. So the application is 
simply receiving the events as usual.

> 3) vaPutSurface with new flag VA_BLEND_DRAWABLE_ALPHA: this flag
> indicates the surface content should blend with drawble content using
> drawable alpha.  Player should clear the alpha to 0 if it wants to get
> a opaque video. vaPutSurface shouldn't alter the drawable alpha value,
> so that the subsequent vaPutSurface still can blend with the UI
> control without any drawable content modification
> pros: it is easy for player?
> cons: new vaPutSurface flag
>
> 4) vaPutSurface with new flag VA_BLEND_SURFACE_GLOBAL_ALAPH: compared
> with 3), the alpha is provide by player/VA. Player should clear the
> drawable color to 0 if it wants to get a opaque video. Before every
> vaPutSurface, the implementation may change drawable content, so
> player need to re-clear the drawable color every time
> pros: no obvious pros compared with 3)
> cons: player needs to clear the drawable every time.

I think we should avoid alpha blending with the underlying drawable as 
some implementations may use a child window for vaPutSurface().

UI controls sound like a non-problem to me. All the necesary functionality 
is already working in place. Even if the use wanted native controls (like 
Gtk or Qt buttons), he would render it as child window already. Otherwise, 
if we wants custom images for the UI, the VA subpicture interface is very 
efficient as you can associate only the needed regions.

i.e. you could create a large VAImage/VASubpicture with all control UIs. 
Then you can vaAssociateSubpicture() the needed bits (e.g. 64x64 regions) 
only quite efficiently.

Regards,
Gwenole.