O/S hooks question

[Jonathan Morton]

>That's not an effective way to do it, it should be keeping a local bitmap of
>the entire screen, and if it needs to locally redraw itself (overlapped
>windows etc), it should get it from it's local cache.

Some clients, which support double-buffering, actually do that.  The Purple
Shark MacVNC viewer is a good example.  Simply switching it into the
foreground doesn't require a network request or redraw, as it just blits
from an internal framebuffer when set into this mode.  Takes more memory
though, depending on the server's screen mode.


>It would also overcomplicate clients.  I think a more effective method would

overcomplicated clients is NOT a good thing, this is true.  We're having
enough difficulty getting some of the existing ones working by the sound of
it...


>would also effectively lay the way for sending the mouse cursor only once
>when it changes, and then using a special 16x16 buffer, that's blitted onto
>the screen (we'll need special raster operations on the blits too).
>This would be more efficient than just bitblitting from what is on the
>actual screen, and a heck of a lot faster (the ability for a viewer to
>simply blit from one local buffer to another is MUCH faster than having to
>draw from data over the network).

Apart from the fact that not all computers have hardware-cached
mousepointers.  X does, or at least stores it separately in memory and
doesn't let the software see it in the main framebuffer even if the
hardware can't hack it (this seems to be rare - even the ancient CL 5424
chipset in a 486 i set up with Linux last week seems to support hardware
mouse).  However my PowerBook 5300 does not, and I had to make a
modification to the MacVNC Server precisely for this reason.

IMHO, the current system works very well indeed, with not much latency
given a reasonable network route between client and server.  Some
improvements could be made, particularly direct - and optional - support
for SSH (security) and Zlib (compression) in the protocol.  (i know some
people have already published 'hacks' for these, but I haven't yet checked
to see where it fits in the protocol stack).  I think the latter could be
implemented as an encoding method - sending rectangles via a PNG-like
structure is attractive to me, and could be more efficient than HexTile in
certain situations, plus it would be compatible with existing
servers/viewers without the capability.  SSH is slightly more of a problem
to integrate into the protocol itself, but maybe that's because I don't
understand it properly...

One 'intelligent' feature I would like to push forward as an idea, is some
way to balance between encoding data-efficiency and CPU load on the viewer.
What I mean by that, is that while HexTile (and PNG) are very efficient
compression methods for use over a slow link, they are heavy on the CPU at
both ends, particularly the client (which is supposed to be 'thin', yes?).
Now, sometimes I want to connect this 'thin' client to a local machine on
the network, where bandwidth is not a problem, and the CPU power of the
client becomes a factor in the overall latency.  In those situations, it
seems that using Raw or RRE/CoRRE encodings would be the most effective, as
seen by the user - so I would manually deselect the HexTile encoding.
However, if i were then to accidentally connect to a modem user using the
same settings, the latency would be horrible as the modem can't supply that
amount of data.

Some method of allowing the client to benchmark its' own CPU and send it's
speeds on the various algorithms to the server would automate this process.
A method of determining the available bandwidth would also be necessary -
timing the transfer of a known amount of data would achieve this.  The
benchmarks don't need to be industrial-grade, just 'ballpark' measurements
so the server can optimise a bit more.  Also, it should be optional, so a
client simply not sending it's benchmark results 1) does not cause the
server initiate the network benchmark and 2) does not cause the server to
try and optimise the connection once established.

I think the two above suggestions are technically simple to implement
without requireing a massive upheaval in the protocol or
method-of-operation standards - what does everyone else think?

(ducks behind flame-proof shield just in case)

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi "at" cyberspace.org  (not for attachments)
uni-mail: j.d.morton "at" lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.
--------------------------------------------------------------
Contributing to the VNC Project - http://www.uk.research.att.com/vnc/
Ask me for Macintosh VNCserver v3.3.2 beta2.1
v3.3.2 beta 2.2 due out soon!



---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------