Created attachment 18549 [details]
Test-case that demonstrates the breakage
Unfortunately, I can't be very specific about this bug, but it seems that when the associated X window to a GL context is resized, mip-maps are almost always corrupted.
This does not seem to affect GLUT applications (thus the difficulty I'm having in producing a test case), but it does affect Clutter ( http://clutter-project.org/ ) projects.
Attached is a small, annotated clutter application that demonstrates this breakage. This doesn't happen in Mesa 7.0.
Works with GEM, fails on classic mode.
clutter did emit a bunch of assertions. I'd feel more secure if we could get a plain GL testcase.
(./clutter-mipmap:20847): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed
I think this assertion is showing up another bug or odd behaviour in the driver (it doesn't happen on ATI or nvidia, and some versions of the Intel driver don't show it). The assertion means that when we draw the pick buffer (to detect what actor the mouse is over), we're getting a colour back from glReadPixels that doesn't correspond to any actor on the stage - i.e. a colour that we didn't draw. Perhaps it could be related to this?
I used to get this assertion, but since updating to git drivers, I can't reproduce it (but I've not updated in the last few weeks, as tracking git X bits and packaging them is a huge pain and I've not been working on things that are critically affected by these bugs).
Attached is a patch (applies against 0.8 branch) that dumps the pick buffer to /tmp when this assertion is fired. This may help to debug that problem; if I can reproduce it on any of my machines, I'll see what I can find out.
Created attachment 19432 [details] [review]
Patch to dump the pick buffer to /tmp when receiving unexpected results
Oh. You're using glReadPixels which is known to be broken at present. We're working on a fix for that.
Just to clarify, glReadPixels is only used for picking, that does not affect this bug (unless using glReadPixels causes corruption in other things?)
At this point the q3 release has been out for long enough that we're not working on classic mode bugfixes any more. Just confirmed that the testcase displays correctly still (and the assertion failure also doesn't occur) with the current GEM-based code.
Mass version move, cvs -> git