Yes. Personally, I'd also take the change to vnc-enc-zrle.c: because vs->zrle->zlib is reset at the top of the function, using vs->zrle->zlib.offset in determining zstream->next_out and zstream->avail_out is useless.
Cameron Esfahani di...@apple.com "All that is necessary for the triumph of evil is that good men do nothing." Edmund Burke > On Jan 16, 2020, at 11:45 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > > On Thu, Jan 16, 2020 at 07:50:58PM -0800, Cameron Esfahani wrote: >> Remove VNC optimization to reencode framebuffer update as raw if it's >> smaller than the default encoding. QEMU's implementation was naive and >> didn't account for the ZLIB z_stream mutating with each compression. Just >> saving and restoring the output buffer offset wasn't sufficient to "rewind" >> the previous encoding. Considering that ZRLE is never larger than raw and >> even though ZLIB can occasionally be fractionally larger than raw, the >> overhead of implementing this optimization correctly isn't worth it. > > So just revert de3f7de7f4e257 then ... > >> In my investigation, ZRLE always compresses better than ZLIB so >> prioritize ZRLE over ZLIB, even if the client hints that ZLIB is >> preferred. > > ... and make this a separate patch? > > cheers, > Gerd >
