Re: [PATCH v1] vnc: fix VNC artifacts

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 1/17/20 10:43 PM, Cameron Esfahani via wrote:
> I’m new to this process, what are the next steps?

Assuming your patch is in a branch named vncfix_v1:

1/ Start new branch based on the commit previous to your patch:

   - git checkout -b vncfix_v2 vncfix_v1~

2/ Revert the offending patch, explain in commit description why:

   - git revert de3f7de7f4e257

3/ Apply the rest of your patch on top, git-cherry-pick is smart to 
directly use the diff context. Verify the patch is correct and rewrite 
the commit description:

   - git cherry-pick vncfix_v1

4/ Send the 2 patches as a series to the mailing list

> 
> Cameron Esfahani
> dirty@apple.com
> 
>> On Jan 16, 2020, at 11:47 PM, Gerd Hoffmann <kraxel@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
>>
>>
>