The Blender-on-G400 issue

[Brian Paul]

Glynn Clements wrote:
> I have the problem with Blender on a Matrox G400, described in:
> 
> http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/016438.html
> 
> It appears that the G400 driver is getting its front and back buffers
> confused in certain situations. This is a problem for Blender as the
> code extensively mixes drawing to both buffers.
> 
> I have tracked it down so far as adding debugging code to Blender's
> shaded_button function in source/blender/src/interface_draw.c. This
> code draws the (gradient-filled) background for UI buttons. AFAICT, it
> always draws to the back buffer; or, at least, it is meant to.
> 
> Adding:
> 
> 	glGetIntegerv(GL_DRAW_BUFFER, &db);
> 	fprintf(stderr, "shaded_button: %d\n" , db);
> 
> results in lots of lines of the form:
> 
> 	shaded_button: 1029
> 
> The value is always 1029 (== 0x0405 == GL_BACK).
> 
> However, adding code to dump out both the front and back buffers (via
> glReadBuffer + glReadPixels) to PPM files at the beginning and end of
> the function shows that it is actually drawing to the front buffer. 
> 
> The button backgrounds then get overwritten by the text or icon, which
> *are* drawn to the back buffer then copied to the front buffer using
> glCopyPixels.
> 
> If I add:
> 
> 	glDrawBuffer(GL_BACK);
> 
> immediately after the above lines, the problems go away (for buttons;
> other parts of the UI, e.g. menus and tooltips, are still
> transparent).
> 
> Given that glGetIntegerv(GL_DRAW_BUFFER) says that it's already using
> the back buffer, and that the problem doesn't occur with Mesa (or
> presumably other DRI drivers), it looks as if glDrawBuffer() may not
> be working correctly.
> 
> Does anyone have any suggestions on where to go from here?

I'd use gdb to set some breakpoints in the mga driver, starting at 
mgaDDDrawBuffer() to make sure it's doing what's expected.

Alternately, you might try to write a small test program to repro the bug.

-Brian