[Wayland-bugs] [Bug 78190] protocol: Reporting damage in surface coordinates doesn't work with EGL

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78190

--- Comment #6 from Jason Ekstrand <jason at jlekstrand.net> ---
The next question, that comes to my mind is how to define damage in certain
edge-cases.  In particular, what happens if the buffer_transform, buffer_scale,
or viewport is changed?  If you attach with a non-zero (dx, dy), how is damage
treated?  My inclination is to say that damage is relative to the previously
attached buffer with no respect to any transforms.  In order to analyze this,
let's look at a few case-studies.

1) A client re-paints the same image only rotated to handle a rotated output. 
In this case, the difference between the two buffers will most likely be almost
total (unless the drawn image has some symmetry somewhere).  If it's an SHM
buffer, we will have to either do a full texture upload or some sort of
CPU-side transformation.  However, from a surface perspective, the contents
haven't changed at all and the compositor doesn't need to repaint.  I think the
solution here is that clients shouldn't be changing the buffer_transform all
that often and that the one-time cost of a full repaint is ok.  Also, the
client can wait until something actually changes on its surface before
repainting everything transformed.

2) A video client adjusts wl_viewport on a surface and re-attaches the previous
buffer.  Here having damage relative to the last-attached buffer saves us.  We
can avoid the texture upload and the compositor will no that, because the
wl_viewport was changed, that it needs to repaint that portion of the screen.

3) A client resizing from the top or left.  Previously, if the contents in the
lower-right didn't change, the client could only damage the upper-left edge
that is moving.  With buffer-coordinates, you only really have resizing from
the lower-right, so you'll have full damage in this case.  If it's a DRM
buffer, you're going to have to re-allocate and the client will have to do a
full repaint to resize anyway.  The cost of the compositor repainting the
entire surface will be relatively small compared to this.  On the other hand,
if it's an SHM buffer, the compositor is either going to have to do something
very clever or it will have to blow the whole texture and re-upload because
there's no way to tell OpenGL to take the current texture contents and shift
them down and to the right.

One thing that keeps coming up in every example I can think of is texture
upload for SHM buffers.  If the damage is in surface coordinates, the
compositor has properly track all of the damage and where it maps to on the
buffer and what has happened with the buffer in order to figure out the right
portions of the image to re-upload.  If damage is in buffer-coordinates
relative to the previously attached buffer, this is a non-issue.  My little
weston-damage client didn't demonstrate this, but I'm pretty sure that Weston
is broken with respect to suddenly changing buffer_transform and not reporting
damage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20140507/26e6e1fb/attachment.html>