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

[Frediano Ziglio]

> 
> 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?)
> 

Not that I know. But we could do it using statistics and replay.

> > Is not clear when JPEG is used. Looks like is used instead of QUIC if lossy
> > compression is enabled. But not always (for instance when we are sending an
> > image with red_marshall_image and we selected QUIC as default compression).
> > The LZ/GLZ algorithms do not support images with extra stride. But the
> > fallback if this happens is not clear (can be none or QUIC).
> > For LZ4 there is a client capability (SPICE_DISPLAY_CAP_LZ4_COMPRESSION)
> > but
> > there is no such capability for LZ/GLZ. Looks like LZ/GLZ are used only if
> > AUTO_GLZ/AUTO_LZ/GLZ/LZ are selected (so the image compression setting in
> > this case define the capability).
> 
> lz/glz have been there forever, lz4 was added 'recently', so
> client/servers have to be able to know whether lz4 is supported or not.
> That's the reason there is a lz4 cap, but no lz/glz cap.
> 
> Christophe
> 

So:
  off -> uncompressed
  quic -> use quic or jpeg
  lz -> use lz if possible but don't try quic/jpeg
  glz -> use glz if possible if not lz if not uncompressed
  auto_lz -> use lz if possible or try quic/jpeg
  auto_glz -> use glz if possible if not lz if not quic/jpeg
  lz4 -> use lz4 if possible if not uncompressed

Does it make sense as a ruleset?

Why there is no auto_lz4 ??

Frediano