https://bugs.freedesktop.org/show_bug.cgi?id=93094
--- Comment #5 from Pekka Paalanen <[email protected]> --- Oh you were talking about continuously resizing the window! Sorry, I didn't get that. Yes, resizing a window is a very heavy operation, not only causing repaints and content relayouts, but often also buffer reallocations. This is because windows practically always have content that is not a single solid color, which actually requires a full repaint when resized. If you don't want the incurred system load, you have to go back to outline resizing instead of using the modern live resizing. Another option is to have the compositor just scale the old image and signal the size change to the app only when the mouse button has been released. Both alternate resizing methods can be implemented in a compositor without any protocol changes. I do not think it makes any sense to try to optimize resizing for a solid color surface, because really, what's the use case? That said, and as I already pointed, there is a way to avoid redrawing huge shm buffers all the time when all you got is a solid color: use 1x1 buffer and wl_viewport. The protocol spec has been written, and Weston has an implementation. It's just that there is no Weston demo that would only draw a solid color surface, because it would be useless. If windows do not have identical content, there is no memory you could save by de-duplication, because nothing is duplicated. Getting a pre-filled shm buffer and then "work with him as with the original wl_buffer" saves nothing, because every such buffers needs to be a new instance and painted to the pre-fill color, because the app would be drawing its own thing into that buffer. There is nothing to be gained, and if the compositor were to hand out pre-filled buffers, the compositor would take the performance hit across the whole desktop rather than just the one application. It is more heavy to copy a buffer from another, than to fill one with a color. -- 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
