Re: gtk+2.8.x and cairo

[Mark Kettenis <mark kettenis xs4all nl>]

> From: Owen Taylor <otaylor redhat com>
> Date: Wed, 14 Dec 2005 16:32:02 -0500
> On Wed, 2005-12-14 at 14:26 -0500, Kurt Miller wrote:
> > Hi,
> > 
> > There is a rather significant cairo bug that can cause all gtk+2 based 
> > apps to sefault upon startup in some X server setups. The problem can 
> > be seen across archs (sparc/sparc64/macppc/i386) and OS's and seems to 
> > be easist to reproduce when the X server is at Depth 8. 
> > 
> > I know this is a cairo bug, but it effects all gtk+2.8.x based 
> > applications when a machine happens to be configured such that the bug 
> > it hit. In some cases it is not possible to configure the X server to 
> > avoid the bug, so it makes all gtk+2 apps not useable.
> > 
> > I'm writing this list in an attempt to raise awareness of the bug.
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=4505

> I'd basically consider GTK+-2.8 to require something better than 8pp;
> I know there are people who love to get new software running on
> ancient hardware, but PseudoColor really is a different and complex
> world. Getting PseudoColor support working reasonably was one of the
> most time-consuming parts of GTK+-0.9x development.

Was this a deliberate decision by the GTK+ developers?  If so, is it
really that unreasonable to expect "simple" GTK+ applications that
only need simple widgets to build a GUI (i.e. a word processor or
e-mail client) which worked fine on 8bpp displays using GTK+ 2.6, stop
working correctly if you rebuild them using GTK+ 2.8?

> (And the CPU that goes along with that vintage of hardware is going
> to perform pretty badly for Cairo ...)

But the application could run on a machine with a powerful CPU,
displaying on an X-terminal, couldn't it?

> That being said, it really shouldn't segfault; but it's not something
> within what the scope of the Cairo developers test on or can support
> themselves. If you catch up with Keith Packard on #cairo, I think he
> had some ideas about how PseudoColor could be supported in cairo
> without causing excessive complexity to leak into the normal code.

It'd be great if it could be fixed.  But if it can't, shouldn't there
be an alternative?

> If the issue is 8/24 hardware defaulting to 8bpp, then it might make
> sense to have some environment variable or XSetting to make the GTK+
> default visual the GdkRGB visual rather than the system visual.

It's more a question of 8bpp hardware defaulting to PseudoColor rather
than TrueColor.  Now, defaulting to PseudoColor certainly makes sense
for such hardware, but it seems it is not the optimal choice for
gtk+/cairo based applications.  So perhaps gtk+ and/or cairo could
choose a TrueColor visual over a default PseudoColor visual if
available?

Mark