Menu
▾
▴
Re: [Mesa3d-users] (Lack of) Single buffering in software XFree86 4.1 Mesa
|
From: Brian P. <br...@tu...> - 2002-06-12 03:56:35
|
Geoffrey Broadwell wrote:
> THE SHORT STORY
> ===============
> Originally I discovered that the software Mesa built in to
> XFree86 4.1 did not provide alpha-enabled visuals, and Brian
> fixed that for me. Now I notice that it does not provide
> single-buffered visuals, and I'm curious why, and whether
> that should fixed as well, or if it is intended behavior.
>
>
> THE LONG STORY (AKA HISTORY OF THE HUNT)
> ========================================
> Some time ago, I was having problems getting Perl's OpenGL
> library to work with my XFree86 4.1 software Mesa install.
> Given that the Perl library was complaining that it could
> find no visual matching its requested attributes, I guessed
> that the problem had to do with the fact that my install
> did not support any visuals with an alpha channel.
>
> So I sent a question to this list asking why this was so,
> and after a couple of (very fast, thanks!) email exchanges
> with Brian, he provided me with a patched libGLcore.a that
> created some alpha-supporting visuals. When I dropped the
> new libGLcore.a into place, glxinfo reported the new alpha
> visuals, and I was quite happy. Until I ran the Perl GL
> sample code and got the same error I used to. Bleah.
>
> At that point, life intervened, and I just today came back
> to take a look at the problem. I figured that glxinfo was
> finding visuals happily, so whatever was different between
> the glxinfo method and the Perl OpenGL.pm method must be
> my problem. I downloaded a copy of the XFree86 4.1 source,
> found the glxinfo.c file, and started looking through it,
> finally happening on the following snippet:
>
> visinfo = glXChooseVisual(dpy, scrnum, attribSingle);
> if (!visinfo) {
> visinfo = glXChooseVisual(dpy, scrnum, attribDouble);
> if (!visinfo) {
> fprintf(stderr, "Error: couldn't find RGB GLX visual\n");
> return;
> }
> }
>
> whereas Perl's library has the following snippet:
>
> vi = glXChooseVisual(dpy, DefaultScreen(dpy),attributes);
> if(!vi)
> croak("No visual!");
>
> Further research showed that Perl's default visual attributes
> array was just {GLX_RGBA, None}; in glxinfo.c, attribSingle
> and attribDouble are defined with:
>
> int attribSingle[] = {
> GLX_RGBA,
> GLX_RED_SIZE, 1,
> GLX_GREEN_SIZE, 1,
> GLX_BLUE_SIZE, 1,
> None };
> int attribDouble[] = {
> GLX_RGBA,
> GLX_RED_SIZE, 1,
> GLX_GREEN_SIZE, 1,
> GLX_BLUE_SIZE, 1,
> GLX_DOUBLEBUFFER,
> None };
>
> Noticing that the difference between the two was only the
> addition of GLX_DOUBLEBUFFER, I added that in to the Perl
> attributes (to make {GLX_RGBA, GLX_DOUBLEBUFFER, None}),
> added an appropriate glXSwapBuffers() call in the test app,
> and everything worked.
>
> Aha! So now I went back and looked again at the output of
> glxinfo, and sure enough, no single-buffered visual (db = y
> in all cases):
>
> ====
> visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
> id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
> ----------------------------------------------------------------------
> 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
> 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
> 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
> 0x26 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
> 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
> 0x28 24 dc 0 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
> ====
>
> So now the question becomes, is this intended behavior?
Yes.
> Or should there be single-buffered visuals, in case an
> app expects them?
The GLX specification does not require that there be both single and
double-buffered visuals. Since at least 99% of all OpenGL apps use
double-buffered visuals, we didn't think that single-buffered visuals
were necessary.
A well-writen OpenGL app that needs a single-buffered visual should
fall back to rendering to the front buffer (i.e. glDrawBuffer(GL_FRONT))
of a double-buffered visual if that's all that's available.
The GLUT toolkit does this, if you're looking for an example.
Just FYI, the OpenGL spec doesn't require the presence of double-
buffered visuals, depth buffers, stencil buffers, accum buffers,
or alpha channels. All that's really required is at least one
RGB or color-index color buffer. But that's not very practical
so you can usually expect to find at least a visual with double-
buffered RGB and a depth buffer.
> In my case, I can happily go about my business, since
> unlike the lack of alpha channel, the lack of single-
> buffering doesn't hurt me. But I can imagine that
> *someone* might care. At the very least, several of the
> Perl OpenGL sample apps don't work without fixes . . . .
>
> *whew!*
I'd say that the Perl examples are broken if they can't cope without
single-buffered visuals.
Over the years I've seen a _lot_ of OpenGL programs that don't handle
GLX visuals correctly.
-Brian
|