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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel