[GRASS5] XDRIVER colour changes

GRASS GRASS developer
1

I've just committed a bunch of non-trivial changes to XDRIVER's colour
handling. If they cause anyone problems, the previous version can be
retrieved using the "color_changes_20010502" tag.

The changes should result in better output in "fixed" colour mode on
all visual types. I've tested it on XFree86, on 8/15/16/24-bit
TrueColor and DirectColor visuals, and on 4/8-bit StaticGray,
GrayScale, StaticColor and PseudoColor visuals (needless to say, 4-bit
visuals don't produce particularly nice output).

If anyone has a system with other visual types, feedback would be
appreciated.

Also, I had to force the use of a private Colormap for DirectColor
visuals, mainly due to being unable to figure out how to do any colour
handling other beyond filling an empty Colormap with writable colour
cells.

If anyone knows of some worthwhile[1] documentation on the details of
X Colormap handling (and DirectColor visuals in particular), I'd
appreciate the information.

[1] as opposed to the X manpages and the Xlib documention in
xc/doc/hardcopy/X11.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Wed, May 02, 2001 at 09:24:18AM +0100, Glynn Clements wrote:

I've just committed a bunch of non-trivial changes to XDRIVER's colour
handling. If they cause anyone problems, the previous version can be
retrieved using the "color_changes_20010502" tag.

The changes should result in better output in "fixed" colour mode on
all visual types. I've tested it on XFree86, on 8/15/16/24-bit
TrueColor and DirectColor visuals, and on 4/8-bit StaticGray,
GrayScale, StaticColor and PseudoColor visuals (needless to say, 4-bit
visuals don't produce particularly nice output).

If anyone has a system with other visual types, feedback would be
appreciated.

Also, I had to force the use of a private Colormap for DirectColor
visuals, mainly due to being unable to figure out how to do any colour
handling other beyond filling an empty Colormap with writable colour
cells.

If anyone knows of some worthwhile[1] documentation on the details of
X Colormap handling (and DirectColor visuals in particular), I'd
appreciate the information.

[1] as opposed to the X manpages and the Xlib documention in
xc/doc/hardcopy/X11.

the new fixed are working well on Linux/x86 (Xfree4.0.2, KDE2, depth of
root window: 16 planes according to xdpyinfo).

BTW: I have just added percentage output to d.rast. This is useful for large
maps to tell the user that d.rast is working unless the map is finally
displayed). Hope that's o.k. with everyone.

Regards

Markus

PS: Solaris compile is running for testing the Xdriver...

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Wed, May 02, 2001 at 09:24:18AM +0100, Glynn Clements wrote:

I've just committed a bunch of non-trivial changes to XDRIVER's colour
handling. If they cause anyone problems, the previous version can be
retrieved using the "color_changes_20010502" tag.

The changes should result in better output in "fixed" colour mode on
all visual types. I've tested it on XFree86, on 8/15/16/24-bit
TrueColor and DirectColor visuals, and on 4/8-bit StaticGray,
GrayScale, StaticColor and PseudoColor visuals (needless to say, 4-bit
visuals don't produce particularly nice output).

If anyone has a system with other visual types, feedback would be
appreciated.

Also, I had to force the use of a private Colormap for DirectColor
visuals, mainly due to being unable to figure out how to do any colour
handling other beyond filling an empty Colormap with writable colour
cells.

If anyone knows of some worthwhile[1] documentation on the details of
X Colormap handling (and DirectColor visuals in particular), I'd
appreciate the information.

[1] as opposed to the X manpages and the Xlib documention in
xc/doc/hardcopy/X11.

Glynn,

the solaris compile is done. At least working remote on solaris
fails:

d.mon x0
ncolors: 65536

(sometimes I get:
Can't bind to socket for monitor <x0>. Already in use?
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
Problem selecting x0. Will try once more
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
)

Then the window opens, but I still see my Linux KDE background.
Wiping with another window or iconizing/resizing makes it black.

d.rast nations

Monitor remains as it is, wiping with another window or iconizing/resizing
makes the map visible. It seems to be a backing store problem.
Note: I didn't change anything on Linux, it must have to do with working
on the SUN remotely.

Sorry for no better news, please tell me how to help debugging...

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Markus Neteler wrote:

the solaris compile is done. At least working remote on solaris
fails:

d.mon x0
ncolors: 65536

(sometimes I get:
Can't bind to socket for monitor <x0>. Already in use?

This message is from the old (pre-merge) version (SWITCHER.c):

        fprintf (stderr, "Can't bind to socket for monitor <%s>. "\
      "Already in use?\n", me);

The new version has a slightly different message:

  fprintf(stderr, "Can't bind to socket; already in use?\n");

(I couldn't be bothered passing argv[0] all over the place just for
use in error messages).

I'll ignore the rest of the message unless you tell me that it happens
with the new version.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Wed, May 02, 2001 at 01:43:29PM +0100, Glynn Clements wrote:

Markus Neteler wrote:
> the solaris compile is done. At least working remote on solaris
> fails:
>
> d.mon x0
> ncolors: 65536
>
> (sometimes I get:
> Can't bind to socket for monitor <x0>. Already in use?

This message is from the old (pre-merge) version (SWITCHER.c):

        fprintf (stderr, "Can't bind to socket for monitor <%s>. "\
      "Already in use?\n", me);

The new version has a slightly different message:

  fprintf(stderr, "Can't bind to socket; already in use?\n");

(I couldn't be bothered passing argv[0] all over the place just for
use in error messages).

I'll ignore the rest of the message unless you tell me that it happens
with the new version.

Glynn,

my apologize: It seems that an old lib*.a has been used. After cleaning
and rebuilding the Xdriver runs well on Solaris2.6/SUN.

Thanks for your hint,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'