Robert Arkiletian wrote: > Does tiger vncviewer support bgr233 pixel format? > With tight vncviewer you can specify -bgr233 option but tiger > vncviewer has no such option. I notice tiger Xvnc supports it by > default for 8 bit depth, so I imagine vncviewer should too. > > The reason I ask is that I am developing a GPL application > fl_teachertool which connects many students (via vncviewer) to a > vncserver using vncreflector as a proxy for better performance. > Vncreflector docs state: > > "VNC Reflector is a specialized VNC server which acts as a proxy > sitting between real VNC server (host) and a number of VNC clients. It > was designed to work efficiently with large number of clients, but > current version is optimized to work primarily with clients that > request 8-bit color format known as BGR233. Other color formats are > supported too but performance may be worse if there are many such > clients."
Not sure why that would be the case, but I think Constantin monitors this list, so maybe he can comment. The TightVNC protocol divides each framebuffer update into sub-rectangles and sends each sub-rectangle using a different type of encoding based on the number of colors in the rectangle. If the rectangle is a solid color, then it can be represented as a set of coordinates and a single fill color. If it has two colors, then it can be represented as a set of coordinates, two colors, and a 2-bit bitmap. If it has up to 256 colors, then it can be represented as a set of coordinates, a palette of up to 256 colors, and an 8-bit bitmap. Larger color depths are represented either as raw RGB (which is usually sent as 32 bits per pixel, because that's what the client display requires) or JPEG. Raw, paletted, and mono rectangles are compressed using Zlib prior to transmission. When BGR233 is used, then this forces the server to use only indexed, mono, or solid color encoding and limits the color depth of each rectangle to 256 colors (which, for obvious reasons, causes severe color artifacts with applications that use more colors than this.) I could believe that this used to be less of a burden on the server than JPEG, but I don't think that's any longer the case with TigerVNC, because we use a high-speed JPEG codec that is 2-4x faster/more efficient than the one used by TightVNC. Personally, I would like to see BGR233 go the way of the dodo bird. I have done extensive low-level performance analysis on the Tight protocol with a variety of image workloads, both 2D and 3D, and the best combination of compression options for modern apps seems to be using solid/mono/indexed encoding for very low color depth tiles (like, say, 25 colors or less) and a high-speed JPEG codec for everything else. This is the scheme used by TurboVNC 0.5 and later and TigerVNC. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
