>Is there any way to do a more intelligent updating of the screen when the
>colour map is changed? This particular application is usually only changing
>a few rectangles in the screen, so updating the full screen is a huge amount
>of overhead. Is there any easy way to walk through the screen pixels,
>marking which ones are affected by the colour map change, and generating
>updates from that? I'm assuming that changing the windows and Java clients
>to support colour maps would be too difficult.
Hmmm. A color map and 8bit internal version of the screen will be
required. You can't just say that "Red turned to White, so change all Red
pixels to White", because most apps that use palette cycling rely on having
multiple indices that all have the same color at some point. So we need an
internal palettized storage and internal palette/colormap. Under Windows
this is not hard, and can be done with a DIBSection, which can then be
blitted to the actual screen and GDI will handle the conversion. Or at
least, that's what Microsoft would have you believe. Somehow it never
works out that cleanly... Once you had that internal map, palette cycling
would be trivial.
Dunno enough about Java to know if it has anything equivalent or not. If
not, you could still :
1. Transmit the new palette to the viewer.
2. Viewer walks through old and new palettes, building third "palette" that
simply stores "changed/not changed".
3. Viewer walks through internal 8bit image looking pixel indices up in
change palette. If "changed" then look up color in new palette and perform
SetPixel with new color. Otherwise, ignore.
Very low network load. Very low CPU load on server. Roughly comparable,
but lower CPU load on viewer, since the only alternative is a full screen
download.
Seems doable. Anybody feel like taking the lead, making the patch, and
submitting it?
_____________________________ /"\
Mac Reiter \ / ASCII Ribbon Campaign
Nomadics, Inc. X Against HTML Mail
[EMAIL PROTECTED] / \ (To join the campaign, simply use
this in your signature.)
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
