[Xquartz-dev] 2.4.0_rc2

[Jeremy Huddleston]

This is definitely a bug in rasmol.

First off, it's failing in XCreateImage because it's passing 64 in as  
the bitmap_pad, but that's not a valid value:
http://tronche.com/gui/x/xlib/utilities/XCreateImage.html

Once I changed it to 32, rasmol started...

There are quite a number of '____ cast to ____ of different size'  
warnings throughout the build.  I have no doubt that there are other  
lurking issues... but so far it looks like an issue in rasmol becasue  
it assumes the size of types.

--Jeremy

On Aug 10, 2009, at 18:11, Jeremy Huddleston wrote:

>
> On Aug 10, 2009, at 17:57, Jack Howarth wrote:
>
>> Jeremy,
>>  The code in question is avalable for viewing at...
>>
>> http://www.openrasmol.org/software/rasmol/src/x11win.c
>>
>> At first glance, it appears that for 8-bit visuals, the
>> PseudoColor visual is used...
>
> In which case, you would need to run the X11 server in "256 Color"  
> mode in X11's preferences... The PseudoColor visual only works in  
> 8bit mode.
>
>> #ifdef THIRTYTWOBIT
>>   if( XMatchVisualInfo(dpy,num,32,TrueColor,&visinfo) ||
>>       XMatchVisualInfo(dpy,num,32,DirectColor,&visinfo) )
>>   {   PixDepth = 32;
>>   } else if( XMatchVisualInfo(dpy,num,24,TrueColor,&visinfo) ||
>>              XMatchVisualInfo(dpy,num,24,DirectColor,&visinfo) )
>>   {   PixDepth = 24;
>>   } else /* No suitable display! */
>>   {   XCloseDisplay(dpy);
>>       return(0);
>>   }
>
> Ok, so XMatchVisualInfo(dpy,num,24,TrueColor,&visinfo) should  
> certainly match something... what does 'xdpyinfo' say is available?
>
>> ...which explains the visual not found error message on x86_64 fink
>> for the Radeon X1600.
>
> Really?  How?  You should be getting a 24bit TrueColor visual...
>
>> However, it would appear that TrueColor or
>> DirectColor visuals could be used for 16 and 32 bit. On the Radeon
>> X1600, the 16-bit version produces the visual not found error
>
> really? It looks like it should find a 15bit visual.
>
>> whereas
>> the 32-bit version of rasmol produces the error...
>>
>> Renderer Error: Unable to allocate frame buffer!
>
> That's likely an error with its use of GLX after it was able to get  
> a visual...
>
>> On an HD2600, no matter what I set PIXELDEPTH to, the program runs
>> fine but reports a 24-bit pixel depth (which oddly isn't one of the
>> options in the source).
>
> /shrug
>
>> When I run...
>>
>> bash-3.2$ export LIBGL_DIAGNOSTIC=1
>> bash-3.2$ export LIBGL_DUMP_VISUALID=1
>>
>> all I get is...
>>
>> bash-3.2$ rasmol
>> RasMol Molecular Renderer
>> Roger Sayle, August 1995
>> Copyright (C) Roger Sayle 1992-1999
>> Version 2.7.2.1.1 January 2004
>> Copyright (C) Herbert J. Bernstein 1998-2004
>> *** See "help notice" for further notices ***
>> [32-bit version]
>>
>>
>> Renderer Error: Unable to allocate frame buffer!
>
> Then it hasn't even bothered to make a GLX call... or you're not  
> linking against our libGL.
>
>> xpdyinfo shows...
>> ...
>> default visual id:  0x24
>> visual:
>>   visual id:    0x24
>>   class:    TrueColor
>>   depth:    24 planes
>>   available colormap entries:    256 per subfield
>>   red, green, blue masks:    0xff0000, 0xff00, 0xff
>>   significant bits in color specification:    8 bits
>
> You should be finding this visual...
>
>> ...
>> visual:
>>   visual id:    0x263
>>   class:    DirectColor
>>   depth:    24 planes
>>   available colormap entries:    256 per subfield
>>   red, green, blue masks:    0xff0000, 0xff00, 0xff
>>   significant bits in color specification:    8 bits
>
> This doesn't look like a recent server release.  Are you sure you're  
> using a recent server?  What does X11->About X11 say the version is?  
> We should not be providing any DirectColor visuals any more...
>
>
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev