[RFC] Weston sprite support

[Juan Zhao]

(Sorry for forgetting the list.)

-------- Forwarded Message --------
From: Juan Zhao <juan.j.zhao at linux.intel.com>
To: Jesse Barnes <jbarnes at virtuousgeek.org>
Cc: krh at bitplanet.net
Subject: Re: [RFC] Weston sprite support
Date: Thu, 12 Jan 2012 00:09:17 +0800


On Fri, 2012-01-06 at 11:36 -0800, Jesse Barnes wrote:
> I just wanted to get a direction check on this, there are still many
> open questions.
> 
> The overall goal here is to be able to use overlay planes to display
> surfaces at repaint time if possible.  For long lived surfaces getting
> lots of changes, this can be a big power win since the plane blender is
> a bit more efficient than using the GPU to blit & blend surfaces
> together for final presentation (at least that's the theory).
> 
> Overall, the compositor has to walk the surfaces at repaint time anyway,
> so at that time we'd also like to allocate sprites to surfaces and then
> switch back to GPU blending as needed (e.g. if opacity changes or one of
> the sprite limitations is hit, e.g. the scaling factor).
> 
> These two patches just push the repaint code into the low level
> compositors to facilitate things, but there's lots more to do:
>   - add a function to tell us whether a sprite can be used for a surface
>   - add code to associate a surface with a sprite and break it as needed
>     (this may mean sub-classing the surface type on the drm side to
>     track sprite usage)
>   - handle simple clipping with color keys
>   - handle simple scaling using the sprite src vs dest rectangle size
>   - track surface pixel format types through gbm or wayland proto
>   - potentially add hinting to surfaces indicating the compositor should
>     prefer them for sprites over other surfaces
> 
> Any comments about things?  Is this a sane direction or do people have
> other preferences?
This sprite support can benefit multiplane support on TV a lot. Thank
you so much!

For the multiplane usage on TV, the window plane is configured as ARGB,
so that we can "cut out a hole" on it. I think it is just like some
"alpha=0" colorkey in the framebuffer. 
So some special requirement raised from TV like HW, the window plane
should provide some interface to be configured as ARGB, and the color
format of colorkey can be extended to ARGB for such kind of multiplane
support.
And, it's our pleasure to do it.
Any thoughts?

Thanks, 
Juan