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? > > 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part