On Thu, 2005-06-30 at 17:36 +0100, David Saxton wrote: > On Thursday 30 Jun 2005 14:26, you wrote: > > You don't really give us enough information to guess here. (My initial > > reaction is: that can't happen!) > > > > But we'd appreciate a bug in bugzilla, with: > > > > - Your GTK+ version > > - Information about your operating system (what distro and version, > > if Linux) > > - Information about your X server > > - The output of 'xdpyinfo' as an attachment > > > Before filing a bug with gtk, I want to check that it isn't either a bug > elsewhere (such as in X). > > The output of 'xdpyinfo' gives (amongst other things) this interesting item: > > visual: > visual id: 0x3e > class: DirectColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0x0, 0xff > significant bits in color specification: 8 bits > > where presumably the "0x0" for the green mask is causing the problem - indeed, > 0 is the value in visual_list in the _gdk_visual_init function returned from > XGetVisualInfo for that visual. > > All the other visuals (as shown by xpdyinfo) have non-zero masks. This looks very much like an X bug ... I have no idea what this could mean... you could have only images that were different shades of red and blue. On the other hand, I don't think that GTK+ should go into an infinite loop here, and it's easy enough to catch and avoid. So a bugzilla bug would be appreciated. Since it's a DirectColor visual, it's almost certainly not your default visual, so it doesn't really matter what GTK+ does with it as long as it doesn't hang. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part