Re: gtk+2.8.x and cairo
On Monday 19 December 2005 10:25 am, Owen Taylor wrote: > On Mon, 2005-12-19 at 10:06 -0500, Kurt Miller wrote: > > I understand that ancient hardware will not be supported forever. > > In my particular case I'm seeing the problem on a < 1 year old > > PowerBook G4 which is currenly stuck at Depth 8. > > Oh come on, that's just not plausible. It's no easier to drive a > graphics card in Depth 8 than in better modes; harder usually. > You just need to do the research to fix your configuration. Unfortunately it is plausible. The radeon driver doesn't work on OpenBSD which leaves me with wsfb. I've tried various uncommitted patches from xorg bugzilla but none have stablized it. Openboot Firmware sets the framebuffer depth to 8. There is a hack to make it switch to a higher bpp, but that doesn't work on my model either. In addition to the OpenBSD/macppc case a few other graphics cards on sparc were mentioned. > (Or, though I hate to say this, use OS X... GTK+ works there under X, > and there's even a native port in CVS.) > > > > 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. > > > > I've updated the bug report with instructions on how to reproduce > > on any platform / driver combination. It should be easy for anyone > > to reproduce now. > > You are assuming we have any interest in reconfiguring our graphics > into something that doesn't meet minimal standards for 5 years ago, > not to mention today. Actually, I was assuming the gtk+2 developers would care to know that they are leaving a class of users (however small) in the dust. > > > 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. > > > > > > 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 seems the best possible solution at this time is for gtk+2 to > > detect when PseudoColor is the default and switch to TrueColor as > > Mark Kettenis suggested. Perhaps you could comment on the > > feasablity of that solution? > > As I said 8bpp TrueColor is not a reasonable graphics configuration. > And I certainly don't believe that if your graphics setup is that > crippled, you'll be able to support multiple visuals at once. (High > end graphics systems from 15 years ago could do multiple 8bp visuals > on different windows...) > > Regards, > Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+2.8.x and cairo
On Wednesday 14 December 2005 04:32 pm, Owen Taylor wrote: > 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. > > (And the CPU that goes along with that vintage of hardware is going > to perform pretty badly for Cairo ...) I understand that ancient hardware will not be supported forever. In my particular case I'm seeing the problem on a < 1 year old PowerBook G4 which is currenly stuck at Depth 8. > 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. I've updated the bug report with instructions on how to reproduce on any platform / driver combination. It should be easy for anyone to reproduce now. > 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. > > 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 seems the best possible solution at this time is for gtk+2 to detect when PseudoColor is the default and switch to TrueColor as Mark Kettenis suggested. Perhaps you could comment on the feasablity of that solution? -Kurt ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+2.8.x and cairo
sent on behalf of Mark Kettenis <[EMAIL PROTECTED]> who isn't subcribed to the list and his email wasn't accepted: > From: Owen Taylor <[EMAIL PROTECTED]> > 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk+2.8.x and cairo
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 Thanks, -Kurt ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
