Re: gtk+2.8.x and cairo

[Matthias Clasen <mclasen redhat com>]

On Mon, 2005-12-19 at 10:15 -0500, Owen Taylor wrote:
> On Mon, 2005-12-19 at 15:16 +0100, Kurt Miller wrote:
> > > > 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? 
> 
> Basically. When it came down to how we were going to spend our time,
> something that was going to be a lot of work, used by very few people,
> and almost impossible for us to test wasn't a priority.
> 
> > 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?
> 
> Drawing is drawing.
> 
> > > (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?
> 
> All GTK+ 2 versions work quite badly on X terminals that don't support
> the RENDER extension, because drawing even the simplest text requires
> pulling data from the X server over the network, and then pushing the
> results back.
> 
> With Cairo, we have the framework to do some quite sophisticated 
> things here and really improve performance in this case ... go almost
> to a VNC-like setup where rendering is being done in the server and
> pushed to the client without any round-trips. But someone would have
> to actually do the work to implement that. 
> 
> > > 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?
> 
> What would an alternative be other than a fix?

2.6.10 is still available...

> > > 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?
> 
> You are saying that your 8bpp hardware has a TrueColor visual? While
> that's not unheard of, it's fairly useless, since there are (among
> other problems) too few grays if you divide 8bpp as 3:3:2 or something
> like that. You really need a more sophisticated division of the space
> (6x6x6 color cube + gray ramp) in a StaticColor or PseudoColor visual
> to get even minimally passable results.
> 

Isn't RENDER setting up such a colormap for depth 8 ?

Matthias