On 9/12/11 7:25 AM, Pierre Ossman wrote: > Your analysis mentioned that the compression levels also affected > the sub-rectangle logic, and it wasn't entirely clear to me how > important that knob was.
Not anymore they don't. In prior versions of TigerVNC, they did. The analysis clearly shows, however, that even when the compression levels did affect the subrectangle encoding logic, anything above 6 was still useless. We're not just talking about one app, either. The tests encompassed 20 very different sample workloads, both from 3D and 2D applications. >> 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. > > That ship has already sailed as you made some changes what the > compression levels mean with regard to sub-rectangles, as well as > changes to the general compression method logic. > > In my world, the settings on the client express an intent with regards > to relative trade-offs between CPU, bandwidth and quality. It does not > express an expectation of specific actions on the server. This is exactly why your proposal doesn't make sense to me. If a user selects compression level 0, they intend for the behavior to be different from selecting compression level 2. In your proposal, compression levels 0-2 would be the same if they were using a TigerVNC server, but they would be different if using another type of VNC server. Further, my study did not encompass other methods of encoding, such as plain Zlib, that also use compression levels 0-9. It is unknown whether 7-9 are useless for those encoding methods, so I don't want to remove them altogether in case there are fringe scenarios in which they may be useful. > I'm not arguing the results of your findings, just how the interface > should be presented to the user. I'd like these two goals to be met: > > a) Users upgrading shouldn't be punished because of older defaults. > > b) Users shouldn't have to tweak their settings when switching between > a TigerVNC server and other ones. > > I'm hoping these aren't conflicting goals. I don't see how users are "punished" because of anything. As the report states, in almost all cases, the new encoder is both tighter and faster for each compression level than the old encoder. For the corner cases in which that is not true, bumping up the compression level by one restored the previous compression ratio. As far as tweaking their settings, of course users have to tweak their settings when switching between TigerVNC and other servers. That has always been the case and always will be. Only our server and TurboVNC support high-speed Tight encoding. If the user is using a RealVNC server, for instance, the compression level may not even be relevant. ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
