On 9/7/11 7:54 AM, Pierre Ossman wrote: >> The viewer GUI has also been modified to reflect the findings from the >> low-level performance study (specifically, that compression levels >> higher than 3 rarely have any benefit and compression levels higher than >> 6 never do. Also, compression level 1 is now the default, since it >> offers the best "bang for the buck.") It is still possible to enter >> level 7-9 in the GUI or specify it from the command line, but IMHO, we >> should pretend as if those levels don't officially exist anymore. If >> someone can show a case in which levels 7-9 produce a demonstrably >> better result than 6, I am eager to examine it. > > I'm thinking that changing the client might not be the best way to deal > with this, for two reasons: > > a) Trade-offs between CPU and bandwidth are now different for our > server than others, making it impossible for users to have a good > default setting. > > b) We're wasting part of the compression configuration range. Minor > issue right now though as I guess we currently have no use for extra > steps. > > I suggest we revert the change on the client and change how the server > interprets the compression setting. A crude example: > > 0-2 => zlib level 0 > 3-6 => zlib level 1 > 7 => zlib level 2 > 8 => zlib level 4 > 9 => zlib level 6 > > This would make sure that a good setting for connecting to the new > TigerVNC server would also be a good setting for older versions, as > well as other implementations. And existing clients wouldn't be > punished for the previous default value. > > Downside would be that we lose access to higher zlib levels, but if > your analysis is correct then we aren't losing anything of value. > > (We could of course add more meaning to the lower levels in the future > to differentiate them, like how aggressively we look for solid rects > or using the comparing update tracker)
Hi, Pierre. You may have missed that part of my analysis, but levels above 6 are equally as useless on older TigerVNC versions, as well as TightVNC (and TurboVNC doesn't use anything above level 1.) Additionally, this change is only to the GUI. You can still select levels 7-9 from the command line. That's because I don't want to take those levels away from the user, in case there is some extremely rare corner case in which they might be beneficial. However, until/unless someone comes forward with a strong case showing where 7-9 are beneficial, I want to heavily discourage the use of those levels. My extensive testing revealed that 4-6 are very rarely useful, and 7-9 never are. Your proposal doesn't make sense, because it changes the behavior of the server relative to other servers (including our own 1.1 server.) It will only cause confusion. If I really had my way, we'd hide 4-6 as well, as those are only useful in very rare corner cases. Hiding only 7-9 is a compromise. I spent hundreds of hours coming to my conclusion, so it's going to take more than a few minutes of reasoning for you to convince me otherwise. ------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
