Silly Question...

Const Kaplinsky const "at"
Wed, 01 Aug 2001 00:29:14 +0000

>>>>> "GB" == Greg Breland <gregory "at"> writes:

CK> Just to let you know. I worked on TightVNC actively during last
CK> two weeks (mostly on Win32 local cursor issues)

GB> What issues with the local cursors are you reffering to?

There are two basic cursor types in Windows from the API point of
view, black-and-white (those standard Win16-compatible ones) and
color. From the other side, there are two pseudo-encodings supported
in TightVNC viewers to understand cursor shape updates: XCursor
(X-compatible monochrome cursors) and RichCursor (representing data in
client pixel format). Win32 TightVNC 1.1p8c supported only XCursor and
B&W Windows cursors on server side, and those "local cursor issues"
was about implementing other types of cursor/encoding combinations and
to re-organize the code to make that possible. Finally, my current
code supports local cursors for any possible type of Windows cursor

GB> I have noticed an unusual amount of server processor usage when
GB> the cursor changes. Even on the server, the cursor takes about 0.5
GB> seconds to change shape. I don't know if it is because of the
GB> processor being bogged down or something tight vnc is doing to the
GB> cursor.

Yes, I've noticed that too, but it's not about my code eating CPU
time. I think my code triggers other CPU-hungry piece of code in some
way. I've located the place where it happens but I'm not sure what
actually is going on there.

I'm not sure I would have the time to investigate this problem for the
1.2 release, let me fix it a bit later. I'm sure it's possible, and
actually cursor shape updates should improve CPU usage on server side
instead of eating more resources as it happens at this moment.

With Best Wishes,
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: