On Wed, 16 Nov 2011 11:14:30 -0600 DRC <dcomman...@users.sourceforge.net> wrote:
> On 11/16/11 5:25 AM, Pierre Ossman wrote: > > JPEG quality level 1 is not what I'm considering a reasonable WAN > > setting, so I'm not sure how realistic these numbers are. Still, I > > think my conclusions are roughly the same. > > Well, then, what are you considering to be appropriate WAN settings? > When my users connect over a 5 Mbps link, they will typically dial down > the quality in TurboVNC to the "Low-Quality JPEG" preset and then use > automatic lossless refresh to send a lossless image during periods of > inactivity. This is the only way to get interactive frame rates with 3D > applications over such a connection. > Our users have generally used a setting of 5 or 6. Anything below that has been deemed to be of unacceptable quality, and high-performance use has as a consequence been deemed unrealistic under those conditions. > > Maybe. Given your current numbers, this might make some sense. But > > since the JPEG quality is unrealistically low (IMO), the numbers are > > currently showing off the CUT at its worst. > > I don't know how you justify that statement. I tested both a > low-quality and high-quality JPEG scenario and reported both. > Sorry, I completely missed that there was another sheet. I only looked at the one that opened first (low quality). I need to recheck your results more properly. On Wed, 16 Nov 2011 18:43:40 -0600 DRC <dcomman...@users.sourceforge.net> wrote: > New spreadsheet attached. Will look over this and get back to you. > I am still in favor of enabling the CUT by default only for compression > level 2 or above-- or, to put it another way, I'm in favor of having > some way for users to be able to select "TurboVNC-equivalent" > performance from the viewer without having to fiddle with the server. I > want TurboVNC users to be able to use the TigerVNC Server as a drop-in > replacement without changing their existing TurboVNC clients. Since the > TurboVNC Viewer always uses compression level 1, that means that if the > TigerVNC Server enabled the CUT for compression level 1, the TigerVNC > Server would run more slowly. Realistically, users aren't going to > fiddle with server parameters or read the man pages (or even read my web > page) to figure out the right server settings. They'll just complain > loudly. This seems reasonable to me. Even if there might be some point to the CUT even at level 1, the ability to easily disable it from the client is a more worthwhile feature. One issue is that the CUT is global for the server. So how should the logic be? I guess it should be disabled only if every connected client asks for a compression level of 0 or 1? > If you want to make 2 the default compression level in the TigerVNC > Viewer, I would be open to that, as long as there is a way for users to > get "turbo" behavior (by selection CL=1) without modifying the > server-side options. That's all I'm asking. As for the exact default value, it depends on the tradeoffs. I'll look at your new report first. > Ultimately, I would like to see the viewer provide > a drop-down menu with preset modes, as TurboVNC and TightVNC do. It > doesn't matter so much to me if the viewer isn't "TurboVNC-equivalent" > by default as long as the user can click a button to make it so. It > does matter, though, if the only way they can get a TurboVNC-equivalent > mode is to start their server session with a special parameter. I'm not familiar with how these menus look, but I assume it is something like the "experience" setting in Microsoft's RDP client. I'm all for such at thing and I believe all the weird technical knobs we have right now should really be hidden under some "Advanced" section. > Another option would, of course, be to expose the CUT as a client-side > parameter. It would require extending the RFB protocol, but it would > provide the maximum flexibility. I'd rather not. I'd like to move more towards having the technical details on the server and the client only exposing the desired tradeoffs from the user. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
