Sprite handling framework

Kristian Høgsberg krh at bitplanet.net
Wed Jan 25 22:12:15 PST 2012

2012/1/25 Kristian Høgsberg <krh at bitplanet.net>:
> On Wed, Jan 25, 2012 at 5:00 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>> Ok these need some actual review.  I have things working here (you can
>> test on a current kernel by enabling the DEBUG_PLANES code) and I think
>> the infrastructure is starting to look ok, especially now that I don't
>> leak fbs on every assignment. :)
>> The new buffer reference code makes things a bit nicer, but they could
>> probably still be easier to follow, so suggestions are welcome there.
>> I'm also definitely open to suggestions on how to split things more
>> finely to make the patches easier to digest...
> I think I'd refactor the output code first, to move
> setup_scanout_surface to compositor-drm.c and add the assign_overlay
> hooks first. Then add the drm_buffer_reference code, then add the
> overlapped tracking, and then move the hw cursor code
> (weston_output_set_cursor) to compositor-drm.c and trigger that from
> assign_overlays.  At that point I think it makes sense to add the
> sprite support.  Aside from the ordering and splitting of patches and
> the couple of comments on the 1/3 patch, I think it looks good.

Ok, I went ahead and refactored the backend output abstraction a bit
towards what I was trying to describe:


I'm quite satisfied with the result, the backend repaint interface is
so much simpler.  I'm done for tonight though, but to add sprite
support here we'll need to make the call to weston_output_set_cursor()
a callout into the backend.  At this point we've just computed
overlapped, but haven't propagated damage down yet.  If we put a
surface into an overlay and clear its damage at this point, it wont
affect the lower surfaces, which is exactly what we want.  The callout
will walk the surface stack and do something similar to
weston_output_set_cursor() for each surface that it decides to move to
an overlay/sprite/plane.  When we transition between sprite or not, we
have to post damage similar to what happens around the
prior_was_hardware if/else statement in weston_output_set_cursor.

As a side note, we really need something like surface groups, the
weston_compositor_top() is pretty gross.


More information about the wayland-devel mailing list