[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 #9 from Jason Ekstrand <jason at jlekstrand.net> ---
Pekka, Yes, I think we're 100% on the same page here.  The compositor will have
to have a bit more logic to properly handle damage when things change.

What we have going on here is that there are two different types of damage in
play: buffer damage and surface damage.  Buffer damage is what has changed
between the previous buffer and the current one.  Surface damage is the the
portion of the surface (buffer transformations included) that has changed. 
Buffer damage is used for SHM texture upload whild surface damage is used to
allow the compositor to only partially repaint.

In the steady state (when the buffer-to-surface transformation matrix isn't
changing) it is fairly easy to derive one from the other.  As soon as some part
of the transformation changes, we have an edge-case and it becomes difficult to
accurately determine one from the other.  Fortunately, we should be running in
the steady-state most of the time so this should only ever be a problem if we
are changing the transform, scale, or viewport.  Most of such changes will
require full damage anyway.

It's worth noting that buffer damage doesn't matter for EGL surfaces or for SHM
when using the pixman renderer.  This is because there is no texture upload and
we are directly copying from the client buffer into the output buffer.  The
only thing that matters in these cases is the compositor's ability to only
partially repaint.  However, as I mentioned above, I don't think it makes much
sense for eglSwapBuffersWithDamageEXT to accept damage in anything other than
buffer coordinates because EGL only knows about buffer coordinates.

Also, resizing from the top-left really isn't any different than resizing from
the bottom-right from a buffer damage perspective.  Most clients will resize
exactly the same from one corner or from the other so, if the menu bar,
decorations, etc. don't change, there could be an upper-left rectangle that's
not damaged in either case.  The only difference is that the compositor has to
fully repaint the surface in upper-left case because the undamaged part isn't
pinned.  Oh, well.

Another option that I don't like would be to have a wl_surface.surface_damage
request that explicitly sets the surface damage and let wl_surface.damage set
the buffer damage.  As I said, I don't like this option and would rather we
just let the compositor infer surface damage from buffer 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/b15224d7/attachment.html>