[PATCH weston 2/2] compositor: Damage the whole surface if the viewport changes

Derek Foreman derekf at osg.samsung.com
Mon Dec 7 13:43:43 PST 2015


On 07/12/15 12:29 PM, Bill Spitzak wrote:
> If there was a buffer damage request, this should not damage the entire
> buffer, since supposedly the client sent the correct damage rectangle. I
> think it would be a good idea to enforce this so that clients changing
> the transform don't send incorrect damage regions (in particular *no*
> damage region) and still cause correct output.

Ah yes, I've indeed hidden that kind of bug.  If we care about that we
can log an error right here if no damage has been posted...

The problem is that gl texture upload and "output damage" end up being
convoluted with our current rendering code - take a look at
weston_surface_damage()...  Right now we have no way to damage the
texture independently of the surface.  Even many different desktop-shell
events cause full texture uploads.

I took a shortcut since I figured redrawing a little bit of extra output
in this case probably wouldn't be a big deal - so I damaged the full
surface which is the easiest way to get a full texture upload.  In the
long term I'm not sure what the ideal solution is.

Maybe this patch shouldn't land, and we need to separate texture damage
and surface/view damage instead.  Which is, of course, a lot more work. :)

> If you are trying to figure out the area of the outputs to recomposite,
> the actual area is the union of the old and new surface regions. Looks
> like you are setting it to the entire output.

It gets clipped to surface later on in the same function, I suppose I
could've been a little more careful - surface->width and surface->height
are indeed valid at that point in the function.


Thanks for looking,
Derek
> 
> On Wed, Dec 2, 2015 at 12:56 PM, Derek Foreman <derekf at osg.samsung.com
> <mailto:derekf at osg.samsung.com>> wrote:
> 
>     Surface damage has a curious relationship with buffer damage.  If we
>     change our buffer orientation, the whole buffer contents will likely
>     change.  The application is really only supposed to tell us what parts
>     of the surface changed, which could still just be a subset.
> 
>     Since the gl renderer uses the damage rectangles for texture uploads, it
>     won't upload the entire buffer contents after an orientation change.
> 
>     To deal with this we just damage the entire surface any time the buffer
>     viewport changes.
> 
>     This fixes weston_simple_damage --rotating-transform when using the gl
>     renderer.
> 
>     Signed-off-by: Derek Foreman <derekf at osg.samsung.com
>     <mailto:derekf at osg.samsung.com>>
>     ---
>      src/compositor.c | 4 ++++
>      1 file changed, 4 insertions(+)
> 
>     diff --git a/src/compositor.c b/src/compositor.c
>     index 33d500e..5a2f3aa 100644
>     --- a/src/compositor.c
>     +++ b/src/compositor.c
>     @@ -2761,6 +2761,10 @@ weston_surface_commit_state(struct
>     weston_surface *surface,
>                             surface->configure(surface, state->sx,
>     state->sy);
>             }
> 
>     +       if (state->buffer_viewport.changed)
>     +               pixman_region32_union_rect(&surface->damage,
>     &surface->damage,
>     +                                          0, 0, INT32_MAX, INT32_MAX);
>     +
>             state->sx = 0;
>             state->sy = 0;
>             state->newly_attached = 0;
>     --
>     2.6.2
> 
>     _______________________________________________
>     wayland-devel mailing list
>     wayland-devel at lists.freedesktop.org
>     <mailto:wayland-devel at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 



More information about the wayland-devel mailing list