O/S hooks question

[Thong Nguyen]

> -----Original Message-----
> From: owner-vnc-list "at" uk.research.att.com
> [mailto:owner-vnc-list "at" uk.research.att.com]On Behalf Of Brandon Ibach
> Sent: Sunday, 6 February 2000 10:58 a.m.
> To: vnc-list "at" uk.research.att.com
> Subject: Re: O/S hooks question
>
>
> Quoting Thong Nguyen <thongnguyen "at" mail.com>:
> > That's how VNC works at the moment :).  Except for the CRC thing.
> >
>    Not quite.  Right after the connection, the server sends the whole
> screen.
That's not correct, the client has to request the whole screen.  The server
doesn't not do this after a connect.

After that, the client makes requests in two situations (in
> the case of the X-windows client, anyway).  First, if it is told to
> redraw part of itself, perhaps because some other window had been
> overlapping it, it requests just that part of the screen.

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.


Secondly,
> after every update it gets, it automatically requests an incremental
> update of the whole screen, so that the server will send any parts
> that have changed.

Yes.

>    The problem is, there is currently no way for the server to just
> tell the client "this rectangle here has changed" without also sending
> all of the data for that rectangle.  The scheme I described in my
> message would allow the client to find out what parts of the screen
> have changed without also getting the data, allowing the client more
> control over what data gets sent, opening the door for caching, as
> well as user-controlled updating, also described in my message.
>

I'm not exactly sure what benefits there would be in the client 'knowing'
part of the screen has changed.  It's pretty hard for the client to
determine what it wants updated when it's changed, anything like that can be
foreced by just not requesting an update in the region of the frame buffer.

It would also overcomplicate clients.  I think a more effective method would
be to give the server the abilty to create "Remote Frame Caches", that way,
the server can create invisble frames.  The server also has the ability to
request blits from the cache to the actual screen, and vice versa.  This
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).

:)

-
Thong (Tum) Nguyen
http://www.veridicus.com
-


---------------------------------------------------------------------
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
---------------------------------------------------------------------