<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#c8">Comment # 8</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:phizhed@gmail.com" title="phizh <phizhed@gmail.com>"> <span class="fn">phizh</span></a>
</span></b>
        <pre>(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=93094#c7">comment #7</a>)
<span class="quote">> With wl_viewport, the compositor does *not* create any kind of buffer of
> size NxM. During compositor repaint, it will just fill the given size with
> the given color in the final framebuffer, which is the cheapest possible
> operation. There is no memory reserved for the NxM image at all.

> Why is that not what you want?

> Do you want to do something with the buffer in the client *after* it has
> been filled with the given color? If so, what do you want to do?</span >

<span class="quote">>> in the final framebuffer, which is the cheapest possible operation</span >

My goal is to slow resize the window, filled in one color, and have a 0% CPU
load. Not understanding the way it works from the inside, I was trying to think
optimization based on API abstractions like wl_buffer and wl_shm_pool. Now we
have to wait wl_viewport support from toolkits..</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>