*** Bug 8083 has been marked as a duplicate of this bug. ***

the complete stack trace for gtk-demo on a Linux display is in
http://bugzilla.gnome.org/show_bug.cgi?id=352834

(In reply to comment #0)
> When I start gtk-demo with DISPLAY on Linux X.org 6.8.2, I get
> 
> SEGV_UNKNOWN - Unknown Error
> #0  0xc10ebf00 in XRenderQueryFormats (dpy=0x400146a8) at Xrender.c:335
> 335     in Xrender.c

I've certinaly never seen the above error before.

> When I start gtk-demo with display on a HP-UX 11.11, I get
> Error: Cairo 1.2.5 does not yet support the requested image format:
>         Depth: 8
>         Alpha mask: 0x00000000
>         Red   mask: 0x00000000
>         Green mask: 0x00000000
>         Blue  mask: 0x00000000
> Please file an enhacement request (quoting the above) at:
> http://bugs.freedesktop.org/enter_bug.cgi?product=cairo

That's the expected behavior if you try to use cairo with a 8-bit pseudocolor
visual. Please see bug #4945 for that issue.

> The same problem occurs with DISPLAY on an SGI, although
> both the HP-UX 11.11 and the SGI have not only an 8bit visual, 
> but plenty of 24bit TrueColor and DirectColor visuals, too.

I don't know why GTK+ might be preferring the 8-bit psedocolor visual over one
of the other available visuals, (unless it's just that the X server advertises
that as the default visual). That would be an annoying thing for the X server to
do, but maybe GTK+ could be made to workaround that.
 
> Then I installed GTK+2.10 and all its libraries that I had compiled
> for HP-UX 11.00 on the HP-UX 11.11... and it worked!
> On all my Linux, HP-UX 11.11 and SGI displays!
> (Though the fonts do not have any anti-aliasing, even on the
> Linux display with XRender extension.)

Antialiasing can depend on settings such as the Xft.antialias X resource or
other settings as can be set via things like the GNOME or KDE font properties
dialogs.

I hope the above helps.

I don't know if there's much more to do in this bug report, (we could close it
as a duplicate of #4945 or else close it as NOTOURBUG so that you could go chase
things down with GTK+), but I don't think there's any new issue for cairo here.

-Carl

> > When I start gtk-demo with DISPLAY on Linux X.org 6.8.2, I get
> > 
> > SEGV_UNKNOWN - Unknown Error
> > #0  0xc10ebf00 in XRenderQueryFormats (dpy=0x400146a8) at Xrender.c:335
> > 335     in Xrender.c
> 
> I've certinaly never seen the above error before.

Sorry, that's not output from 'gtk-demo', but from 'gdb gtk-demo core'
after a SIGSEGV. The rest is in http://bugzilla.gnome.org/show_bug.cgi?id=352834.

> I don't know why GTK+ might be preferring the 8-bit psedocolor visual over one
> of the other available visuals, (unless it's just that the X server advertises
> that as the default visual). That would be an annoying thing for the X server to
> do, but maybe GTK+ could be made to workaround that.
>  
[..]

You're right: The default visual of the HP-UX 11.11 and SGI X servers are 8bits
PseudoColor. 
Though I do not want to tell every user of cairo on HP-UX or IRIX to reconfigure
their X servers. So I have go and beg the GTK+ developpers to choose a better
visual?

There is still something that's irritating me.

Running gtk-demo on HP-UX 11.00 with DISPLAY on HP-UX 11.11 results in "Error:
Cairo 1.2.5 does not yet support the requested image format:". 
If the (only) reason is the 8bit default visual, running gtk-demo on the HP-UX
11.11 with local display should _not_ work. Though it does.
xwininfo tells me that this instance of gtk-demo (with pangocairo) uses an 8bit
visual.

I think you should file a request in GTK+ bugzilla that if the
default visual is pseudo-color and the "GdkRGB" visual is 
true-color, to default to the GdkRGB visual.

(The GdkRGB visual is the visual that GTK+ considers "best" for
image rendering)

I considered at some point making the GdkRGB visual the default,
always but considered it was better to honor the way the system 
was configured.

However, since cairo doesn't work on pseudo-color displays at the
moment and is unlikely ever to work *well* on pseudo-color 
displays, that consideration should override.

I'm going to mark this as NOTOURBUG so the issue of the visual selection can be
followed downstream with GTK+. Meanwhile, there's the separate issue that cairo
could be made to work with a pseudocolor visual, but we already have that as bug
#4945.

-Carl

PS. As for comment #5 it's a mystery to me that you can get cairo to work on any
8-bit visual. Oh, unless perhaps that's an 8-bit truecolor visual? If so, please
see bug #7735.

*** Bug 8089 has been marked as a duplicate of this bug. ***