Re: pBuffer

New Message Reply Date view Thread view Subject view Author view

Rob Jenkins (robj++at++sgi.com)
Thu, 10 Dec 1998 02:11:30 -0800

Ruediger Westermann wrote:
>
> Hello,
> i'm actually trying to use the SGI PBuffer on several different
> machines.
>
> // find an OpenGL-capable visual
> if (((fbConfigList = glXChooseFBConfigSGIX(
> PixBuffer::display, // connection to X server
> DefaultScreen(PixBuffer::display), // default screen number
> PixBuffer::configAttribList, // list of attributes
> &nitems)) != NULL) && (nitems > 0)) {
>
> // find an FBconfig in list with RGB == 8 and Zbuffer > 1
> int match = 0, a[5];
> for(int i = 0; i < nitems; i++) {
>
> glXGetFBConfigAttribSGIX(PixBuffer::display, fbConfigList[i], GLX_RED_SIZE,
> &a[0]);
> glXGetFBConfigAttribSGIX(PixBuffer::display, fbConfigList[i],
> GLX_GREEN_SIZE, &a[1]);
> glXGetFBConfigAttribSGIX(PixBuffer::display, fbConfigList[i],
> GLX_BLUE_SIZE, &a[2]);
> glXGetFBConfigAttribSGIX(PixBuffer::display, fbConfigList[i],
> GLX_ALPHA_SIZE, &a[3]);
> glXGetFBConfigAttribSGIX(PixBuffer::display, fbConfigList[i],
> GLX_DEPTH_SIZE, &a[4]);
>
> printf("r = %d, b = %d g = %d a = %d z = %d\n",
> a[0],a[1],a[2],a[3],a[4]);
> if((a[0] == 8) && (a[1] == 8) && (a[2] == 8) && (a[3] == 0) && (a[4] > 1))
> {
> match = i;
> printf("fbConfigList[%d] matches the selected attribList\n", i);
> break;
> }
> }
>
> On some machines it does work, on others i get the message that the only
> visual that is available is r=12 g=12 b=12 a=12 d=24 but the X-Server
> can't allocate the requested resource.
>
> Does someone knows about a workaround ?
>

I recognise the above :-) It's simple and works well on some machines
but doesn't really do ehough to work on all machines. The issue is two
fold: man glXChooseFBConfigSGIX describes the way the list of potential
matches is returned and ordered, if you lok at the rules for sorting the
returned list the 2nd consideration is:

    2. larger total number of RGBA color components (GLX_RED_BITS,
         GLX_GREEN_BITS, GLX_BLUE_BITS, and GLX_ALPHA_BITS) that
have higher number of bits,

In other words, the list is sorted deepest to shallowest RGB. Now, if
you look at the man page for glXMakeCurrent it tells you that:

     BadAlloc may be generated if the server has delayed allocation of
     ancillary buffers until glXMakeCurrent is called, only to find
that it has insufficient resources to complete the allocation.

So, with the simple search appoach above, if you're on a machine with
enough frame buffer to have RGBA 12 visuals available, the first match
you find will be RGBA12, and if you check, could well have huge
accumulation buffers etc that you don't need. So, this matches your
simple test, you stop searching but presto, it's too big to make a
pbuffer with.

You'd need to play around but some extra things you could add to try and
make it work in all cases are:

o decide what your bare minimum config needs to be, eg RGB >= 5, A = 0,
depth > 1 ( there is no depth = 1, putting 1 means you get the biggest
available ).

o decide on things you'd like to do without, eg accum buffer = 0,
stencil = 0. Be careful not to hardwire for cases where you only
consider the case where they are = 0, search for a match with no accum
buffer but also deal with the case where the only match does have some
accum bits.

o consider traversing the list > once, either search until you have the
minimal match or maybe try glxMakeCurrent but handle the failure with
badalloc and search for a smaller match.

To get a feel for the right approach, look at the output of findvis on
various machines and see the kind range you have to cope with ( bear in
mind that display resolution and channel size will effect the list
return by findvis ).

Hope this helps,
Cheers
Rob

> Thanks
> Ruediger
>
> --
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
________________________________________________________________
Rob Jenkins	Silicon Graphics 	mailto:robj++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Thu Dec 10 1998 - 02:24:35 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.