[RFC] Weston sprite support

Jesse Barnes jbarnes at virtuousgeek.org
Fri Jan 6 11:36:13 PST 2012

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?


More information about the wayland-devel mailing list