glPushAttrib flicker

This is the strangest thing, but glPushAttrib() and glPopAttrib() causes my GL window
to flicker all black when I try to select something. Commenting it out fixes the problem,
but still why is this happening? I’m using an Intel 810E integrated graphics card,
hardware enabled, attribute stack looks good, no GL errors.

can you post a simple test case?

glPushAttrib(GL_LIST_BIT); {
glListBase( some_font_listbase );
glCallLists( strlen(“Testing”), GL_UNSIGNED_BYTE, “Testing” );
} glPopAttrib();

The above code cause the entire GL window to flicker black when selecting something
on screen. Commenting out glPushAttrib(),glPopAttrib() stops the flicker.

In fact I don’t know what GL_LIST_BIT is intended for. It is not documented in my book. I guess you can freely omit it.

It’s for DisplayLists.

It is recommended to push/pop the current display list so OpenGL returns to a neutral state
when you’re done with it.

But I don’t know why this is interfering with my picking routine. Elsewhere I use the OpenGL
selection buffer for picking, and the RenderMode is properly restored back to glRenderMode(GL_RENDER);
so I don’t see the problem.

Is your code running clean (without opengl errors)?

Have you read the spec on these functions and have you satisfied the conditions for normal operation?

Can you post more than a function call or 2? I meant a complete test case. It’s hard to deduce much from a couple of function calls…


In his original post he says he’s not getting any OpenGL errors.

Could you post the relevant portion of code where you push and pop stuff and do your selection?

My guess is that your pushing your render list, and then calling some empty list during your selection which would cause the screen to go black.
Popping the list back you would then have your correct render list again.

…just a thought.

Here is the important stuff from my selection routine:

 glSelectBuffer( num_hits, hits );

 // setup picking projection here


 INT poly_id=1;

 for(INT i=0; i < num_polys; i++) {


       // draw some stuff here



 // restore projection here

In his original post he says he’s not getting any OpenGL errors.
So he did, but I’m not convinced :stuck_out_tongue:

I’m still waiting to see a complete test case. A complete test case is the smallest compilable app that consistently reproduces the problem. You know, so others can run it on their systems to see if the same thing happens.

If by chance this is a driver bug, you’ll need a complete test case for the intel devrel team anyway. Nobody is gonna want to dig through a lot of code to find the problem. Keep it small and simple, but complete nonetheless. It’s good programming practice to try and isolate problems like this in a reproducable way, if for no other reason than to convince yourself that it is or is not your mistake. This can save everyone lots of time in the long run…

Anyways, good luck to you.


Well, unless someone here has an Intel 810E integrated graphics card, I don’t think you’re going to see the problem. I did try the same program on another computer with newer and better graphics card, and did not see the problem.