[RFC] Weston sprite support

[Kristian Høgsberg]

On Fri, Jan 6, 2012 at 2:36 PM, Jesse Barnes <jbarnes at virtuousgeek.org> 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?

I'm concerned about make all of weston_output_repaint an output hook.
There's a lot of non-trivial (at least it took me a while to get it
right) region code in there to analyze the overlap of the surfaces to
minimize the overdraw and to enable the incremental repaint.  I think
we can just do a different type of hook though.  Maybe after
calculating the per-surface damage, we can call into the backend,
which can then look through the stack, decide whether and which
surfaces should use sprites, set that up and then clear their damage.
When the hook returns to weston_output_repaint, the repaint will then
skip those surfaces.

For that to work I think we need two changes: the wl_list_for_each
that applies the per-surface damage (line 820) needs to move up above
setup_scanout_surface().  In fact, I think we can roll
setup_scanout_surface() into that hook and handle pageflipping to
client buffers in the same hook.  It's not all that different.
Attached a patch/sketch.

Kristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sprites.patch
Type: text/x-patch
Size: 3138 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120106/453b4806/attachment.bin>