[Spice-devel] [PATCH spice 1/3] dcc_compress_image: Handle NULL drawable

[Jonathon Jongsma]

On Thu, 2016-01-14 at 12:07 -0500, Frediano Ziglio wrote:
> > 
> > On Thu, Jan 14, 2016 at 10:27:02AM -0500, Frediano Ziglio wrote:
> > > Had a small discussion with Pavel.
> > > We agree that original code is quite complicated and is hard to understand
> > > the final compression format used.
> > > 
> > > So we would like to have some public discussion about the topic.
> > > 
> > > I personally agree we should have a single code deciding the compression
> > > to use.
> > 
> > I definitely agree here. For one, having different compression being
> > used depending on whether the qxl driver is used or not is unexpected
> > (eg if you set image compression to glz, lz will still be used during
> > initial bootup, and then will 'switch' to glz later on. I haven't looked
> > at the code, so there might be good reasons for that).
> > 
> > > 
> > > This is the list of actual compressions:
> > > - AUTO_GLZ;
> > > - AUTO_LZ;
> > > - QUIC;
> > > - GLZ;
> > > - LZ;
> > > - LZ4.
> > > A client can also decide to disable compression.
> > > 
> > > The AUTO_XXX looks like they should use QUIC as a fallback if XXX is not
> > > possible or if an image with high graduality is detected.
> > 
> > (side question, do we have numbers on compression ratio and cpu usage
> > for quic/lz/glz/lz4?)
> > 
> 
> Brief and raw of a Windows replay capture
> 
>         Images  MB before   MB after  Ratio     CPU time
> LZ4     193     24.21       2.43      10.04%    0.04
> QUIC    204     23.11       1.66       7.18%    0.44
> GLZ     190     20.05       1.2        5.99%    0.14
> LZ      202     20.42       2.04       9.99%    0.15
> 
> So why use Quic ?

Interesting data. Indeed, QUIC seems to be the worst choice. from this data, it
seems that you'd want GLZ if you were optimizing for network bandwidth, and LZ4
if you're optimizing for CPU usage. Might be nice to see data for a slightly
larger sample as well.

Out of curiosity, did you write a little utility for doing this benchmark, or
did you just modify the code in-place?? Having a little benchmark utility that
you could run on different replay captures might be a useful thing to have in
the repository...

Jonathon