https://bugs.freedesktop.org/show_bug.cgi?id=78190
--- Comment #8 from Pekka Paalanen <[email protected]> --- 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.
_______________________________________________ Wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
