The Blender-on-G400 issue

[Glynn Clements]

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?

-- 
Glynn Clements <glynn at gclements.plus.com>