Duane Clark dclark@leewardfpga.com writes:
The main ugly hack that is performed here is in determining whether a pixel is a foreground or background pixel. This is done by adding the red, green and blue values for each pixel, and testing whether they exceed an arbitrary threshold. This should probably be a reasonably safe method, since presumably any cursor will have a high level of contrast between foreground and background colors.
It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar.
Alexandre Julliard wrote:
Duane Clark dclark@leewardfpga.com writes:
The main ugly hack that is performed here is in determining whether a pixel is a foreground or background pixel. This is done by adding the red, green and blue values for each pixel, and testing whether they exceed an arbitrary threshold. This should probably be a reasonably safe method, since presumably any cursor will have a high level of contrast between foreground and background colors.
It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar.
Okay, I'll take a look at that, and do the painting locally. I did not really consider speed to be an issue since these are small pixmaps and the function is only called when a cursor is changed. On a 1G Athlon it appears to change instantly, but I'll take it easy on others.
Duane Clark wrote:
It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar.
Okay, I'll take a look at that, and do the painting locally. I did not really consider speed to be an issue since these are small pixmaps and the function is only called when a cursor is changed. On a 1G Athlon it appears to change instantly, but I'll take it easy on others.
I'm running wine over an ssh connection over a cable modem, which exposes a lot of speed issues. Font setup takes forever, for instance, and app repaint happens partly reasonably, partly in slow motion. I encourage developers to test using this sort of slow connection in addition to normal desktops.
- Dan
On Wed, 19 Dec 2001, Dan Kegel wrote: [...]
I'm running wine over an ssh connection over a cable modem, which exposes a lot of speed issues. Font setup takes forever, for instance, and app repaint happens partly reasonably, partly in slow motion. I encourage developers to test using this sort of slow connection in addition to normal desktops.
I agree, testing in such configurations is nice. It also helps with the local area network case where the trick I'm about to reveal is not very effective. To make things faster when you have to go through a slow and/or high latency link: use VNC. This way, operations that require a round-trip to the X server are still fast. And the screen updates arive to me asynchronously so that even if the application redraws stuff 10 times, it's only transmitted once (or perhaps twise) over the network. Tricks: - use ssh port forwarding for security - I usually also turn ssh compression on - specify '-encoding hextile' on the VNC viewer command line otherwise it will use no compression since it believes it connects to the localhost.
With all that it works pretty well. Ah, the power of Unix :-)
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
-
Alexandre Julliard -
Dan Kegel -
Duane Clark -
Francois Gouget