On Wed, Mar 11, 2009 at 01:40:29PM +0100, Pierre Ossman wrote: > The current encoding autoselection is not working very well, and is > fundamentally wrong as it is implemented in the client (which has no > knowledge of the data and what encoding will be the most efficient). > > Fixing this properly is a big task, so it's not something we > realistically can do for 1.0.0. I'd like to put a quick band aid on the > existing logic though to make it work better with what we've got. > > My plan is this: > > - Use JPEG (Tight really) all of the time as the JPEG code is now > running circles around all the other encodings, both when it comes > to CPU usage and compression. That means "Auto" will no longer > change encodings. > > - Improve the "quality" mapping in Tight. It currently tops out at 80% > JPEG quality. This is insufficient as JPEG at 100% (i.e. lossless) > outperforms the other encodings for most things, and JPEG at 93% is > perceptually lossless and even more efficient. I'll also disable > color compression on the higher quality levels. > > - Have the "auto" mode tweak the quality setting dynamically based on > bandwidth. > > I haven't decided what to do about the color reduction options. I'll > need to do more testing first. > > These changes should give us something that, although not perfect in > any way, is blazingly fast compared to the current logic and should > respond better to reduced bandwidth. I've already tested part 2 in my > plan here, and it works fantastically. :) > > I'd like to start implementing this tomorrow, so please object now if > you think this is bad idea. > > I'd also like to reiterate that this is a temporary solution for 1.0.0. > Long term we should have a more intelligent system. >
If non-SIMD JPEG is not so slower than raw encoding we can prefer Tight JPEG encoding all the time. Otherwise we can use JPEG on low and medium bandwidth nets and raw on high bandwidth nets. I think that current algorithm which is currently in CConn.cxx will be reused. We should always send "second preferred" encoding to server in case that server doesn't support JPEG. So, in theory, existing code will be improved this way: for speeds >= 16Mbps client sends "Raw, JPEG, hextile, zrle" for speeds < 16Mbps client sends "JPEG, zrle, hextile" (Note: with JPEG I mean Tight encoding, of course) Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
