https://bugs.freedesktop.org/show_bug.cgi?id=78190
--- Comment #6 from Jason Ekstrand <[email protected]> --- The next question, that comes to my mind is how to define damage in certain edge-cases. In particular, what happens if the buffer_transform, buffer_scale, or viewport is changed? If you attach with a non-zero (dx, dy), how is damage treated? My inclination is to say that damage is relative to the previously attached buffer with no respect to any transforms. In order to analyze this, let's look at a few case-studies. 1) A client re-paints the same image only rotated to handle a rotated output. In this case, the difference between the two buffers will most likely be almost total (unless the drawn image has some symmetry somewhere). If it's an SHM buffer, we will have to either do a full texture upload or some sort of CPU-side transformation. However, from a surface perspective, the contents haven't changed at all and the compositor doesn't need to repaint. I think the solution here is that clients shouldn't be changing the buffer_transform all that often and that the one-time cost of a full repaint is ok. Also, the client can wait until something actually changes on its surface before repainting everything transformed. 2) A video client adjusts wl_viewport on a surface and re-attaches the previous buffer. Here having damage relative to the last-attached buffer saves us. We can avoid the texture upload and the compositor will no that, because the wl_viewport was changed, that it needs to repaint that portion of the screen. 3) A client resizing from the top or left. Previously, if the contents in the lower-right didn't change, the client could only damage the upper-left edge that is moving. With buffer-coordinates, you only really have resizing from the lower-right, so you'll have full damage in this case. If it's a DRM buffer, you're going to have to re-allocate and the client will have to do a full repaint to resize anyway. The cost of the compositor repainting the entire surface will be relatively small compared to this. On the other hand, if it's an SHM buffer, the compositor is either going to have to do something very clever or it will have to blow the whole texture and re-upload because there's no way to tell OpenGL to take the current texture contents and shift them down and to the right. One thing that keeps coming up in every example I can think of is texture upload for SHM buffers. If the damage is in surface coordinates, the compositor has properly track all of the damage and where it maps to on the buffer and what has happened with the buffer in order to figure out the right portions of the image to re-upload. If damage is in buffer-coordinates relative to the previously attached buffer, this is a non-issue. My little weston-damage client didn't demonstrate this, but I'm pretty sure that Weston is broken with respect to suddenly changing buffer_transform and not reporting damage. -- 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
