<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - protocol: Reporting damage in surface coordinates doesn't work with EGL" href="https://bugs.freedesktop.org/show_bug.cgi?id=78190#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - protocol: Reporting damage in surface coordinates doesn't work with EGL" href="https://bugs.freedesktop.org/show_bug.cgi?id=78190">bug 78190</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Jason Ekstrand from <a href="show_bug.cgi?id=78190#c11">comment #11</a>) > The only reason why changing damage coordinates would work is precicely > because it's not backwards compatable. Backwards is broken. If we add a > new request, then EGL implementations will continue to happily report damage > in buffer coordinates to the request that needs surface coordinates and > ignore the one that takes buffer coordinates. You want to fix EGL while breaking everything else, e.g. wl_shm-based apps/toolkits that already implement HiDPI support. It is debatable how much the everything else matters in practice, but it would also be breaking our API/protocol stability promise. The Wayland spec for damage is not broken in itself. It is the EGL API that makes using it always correctly impossible, because it prevents the code inside libEGL that uses the Wayland protocol to have all the necessary information that *is* present in the client. I wouldn't say EGL is broken here either, it's just the combination. To recap, we may currently have two kinds of EGL implementations: a) ones that rely on wl_surface v1, and pass buffer size to damage, and b) ones that use always "infinite" damage, because it is guaranteed to at least work. Right? If an application uses buffer_transform/scale, or wl_viewport, case a) is currently broken. If we changed the meaning of wl_surface.damage coordinates, case a) would become correct, but all non-EGL apps using wl_viewport or buffer_transform/scale would break. Case b) would just continue being sub-optimal and working. What I'm proposing means the broken case a) will remain broken. It should be a known quantity by now, especially due to the case b) workaround. However, existing apps would not be affected: they continue to be correct or broken just like they used to. Yet, EGL implementations that are actually maintained would be able to implement the correct semantics for damage by using the new wl_surface.buffer_damage when it's available. I have no idea how many cases of a) there are, especially ones that combine it with buffer_transform/scale or wl_viewport. I would hope it is small. I also do not know how much would break in non-EGL apps if we changed the wl_surface.damage semantics, but I would guess it is more than the EGL cases that would get magically fixed by it. That is why I would prefer keeping the existing and known behaviour as it is, and offer an opt-in for doing the optimal, correct thing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>