Writing with glBitmap directly to the front buffer when using double-buffering seems to have no effect. Other routines such as GL_QUADS seem to work. Configuration: * ATI radeon X1400 (R520), but the same behavior is observed with LIBGL_ALWAYS_INDIRECT=1 * Fedora 12-packaged mesa-libGL-7.6-0.13. I am using the front buffer directly for a mouse tracker and don't want to have to fully redraw to avoid excessive slowness when run over remote X. Code example: glDrawBuffer(GL_FRONT); /* Erase background first */ glColor3f(0.0,0.0,0.0); glBegin(GL_QUADS); glVertex2i(poslinex,posliney); glVertex2i(poslinex+poslinewidth,posliney); glVertex2i(poslinex+poslinewidth,posliney+poslineheight); glVertex2i(poslinex,posliney+poslineheight); glEnd(); /* draw a character */ glColor3f(1.0,1.0,1.0); glRasterPos2i(poslinex,posliney+poslineheight); glutBitmapCharacter(TextFont,'f'); /* thin wrapper over glBitmap() */ glFlush(); glDrawBuffer(GL_BACK); Expected result: draw an 'f' over a black rectangle Actual result: Black rectangle but no 'f'. Removing the glDrawBuffer() calls and adding glutSwapBuffers() at the end solves the problem and the expected result is achieved.
Actually this was a bug in the radeon dri drivers, and should be fixed in git master now. Can you confirm and close this bug?
(In reply to comment #1) > Actually this was a bug in the radeon dri drivers, and should be fixed in git > master now. Can you confirm and close this bug? Yes, it's fixed. Tested with modified redbook/drawf. Closing..
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.