VNC client expectations
dave "at" cyclicode.net
Tue Jul 9 20:33:01 2002
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?