<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#c9">Comment # 9</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:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>