Hi James, James ''Wez'' Weatherall wrote: > > The rule when writing VNC clients is that they should not perform pixel > translation internally unless they have good reason to do so, such as > having pixel translation hardware. All servers must therefore support > as many pixel formats as they can. The most obvious to support are 32, > 16 and 8 bit truecolour formats. The current Windows VNC viewer > violates this rule and tends to just ask the server for whatever pixel > format is offered.
I had inferred this from the current spec - when I saw that VNCViewer didn't do this I was a little surprised (much like that it accepted a big-endian format for pixel data where my Linux viewer will only work with little-endian pixel data). Has pseudo-colour (palette based) really had much use? I'm wondering because if it's frequently available then this might be a nice way to handle embedded VNC servers (I'm writing just such an implementation for the Ubicom IP2022 right now). If not then I guess 8 bpp true-colour will suffice when effectively providing a remote 1 bpp viewer - sadly it doesn't work so well for a 2 bpp or 4 bpp mono display and I guess a 16 bpp true-colour display would be required to just get greyscales (this is just a little bandwidth hungry). > Protocol version 3.5 was never officially released and something better > is in the pipeline anyway, so just ignore that. In any case, the server > is entirely at liberty to implement a lower protocol version than the > client - the client should not use 3.5-specific features with a 3.3 > server. Equally, a 3.5 server should not use 3.5-specific features with > a 3.3. viewer. Are there any hints anywhere as to how things will be evolving? Thanks, Dave _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
