On Thu, 2016-01-14 at 11:49 -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?) >From a very simple test I did, it seems that quic has the highest cpu usage. > > > > Not that I know. But we could do it using statistics and replay. Good idea. > > > > 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 currently jpeg is used only with auto_lz / auto_glz - dcc.c:1000 > 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? It does, I am just not sure about jpeg compression ? Does it have benefits over quic ? Would be beneficial to have it as another compression type ? > > Why there is no auto_lz4 ?? > If I remember lz4 was introduced for arm/raspberry pi and the main issue was the speed of decoding. LZ4 is faster (?) than other compression methods, so it was probably more useful to just avoid the compression instead of trying LZ or QUIC. Currently the only way how to enable lz4 is to use '--spice-preferred-compression', eg: remote-viewer --spice-preferred-compression=lz4 Pavel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel