[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 #8 from Pekka Paalanen <ppaalanen at gmail.com> ---
Tricky.

Ok, this needs to be thought out from the very beginning.

Postulate: damage needs to be reported in buffer coordinates.

Consequences:

1. Definition: damage describes where the new buffer content differs from the
old buffer content. This is the "opposite" of the current protocol definition.

2. The damage must be in the new buffer's coordinate system. Actually, the
coordinate systems are always equivalent and only the damage clipping rectangle
may differ, as we ignore all transformations and dx,dy of attach which affects
the surface, not the buffers.

3. Simple resizing from bottom/right must at least add damage to be
bottom/right part that is new (anchor in top-left corner). If the size shrinks
and the new content is identical to the old content on the overlapping part, no
damage is needed.

4. Simple resizing from top/left requires full damage, as the contents in the
buffer coordinate system are all moving (anchor in the bottom-left corner).

5. A new buffer with a new buffer transform, even if it the end result in
surface space would be identical, will require full damage. From buffer point
of view, all the contents changes wrt. the old buffer.

6. If the buffer contents stay the same, but wl_viewport is changed, the client
is not required to send any damage.

Those are the unavoidable consequences for the damage that needs to be reported
by a client, AFAICS.

Consequences 3 and 4 are actually dependent on the anchor, not which side is
resizing. (Did I just reinvent "window gravity"??)

It also has further consequences on the compositor. It is no longer the
client's responsibility to compute the damage in surface coordinates. Therefore
the compositor must implicitly add damage in its scene graph when:
- dx,dy of attach changes
- buffer transformation changes
- wl_viewport changes
These changes will change the surface's appearance even if the client does not
change the buffer content.

Damage on the buffer is a completely different thing than a change (damage) in
surface content. Clients will no longer specify where the surface's appearance
changes, but where the buffer contents change.

We lose some corner-case optimizations, and we gain some other corner-case
optimizations, but I think none of those cases matter, because they are not
common. E.g. changing buffer transformation does not happen often, and resizing
a surface very often does require a full redraw, that is full damage, anyway.
It becomes trivial to maintain a copy of the buffer contents (glTexSubImage),
but it becomes more complicated to compute the damage on screen (or does it?).

With these definitions, I think the logic is quite obvious after all. Can you
find a flaw in my reasoning?

Jason, when I read your #6, I didn't feel like I understood it. Now when I did
the thinking myself, it seems like I came to the exact same idea and
conclusions as you did. Right? :-)

Btw, with the current protocol, if a client changes buffer transformation but
issues no damage and no new buffer, it is a client bug. The client is currently
responsible to set the damage where the surface appearance changes.

-- 
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/419d20a1/attachment-0001.html>