<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Protocol: colored buffer"
href="https://bugs.freedesktop.org/show_bug.cgi?id=93094#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Protocol: colored buffer"
href="https://bugs.freedesktop.org/show_bug.cgi?id=93094">bug 93094</a>
from <span class="vcard"><a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> <span class="fn">Pekka Paalanen</span></a>
</span></b>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>