Comment 35 for bug 771875

Did a debug session today, since I think, this lightweight safeing of parts of the screen is really a plus over complicated screenshot programs.

Here what I found (I've started with compiz code today, so no real know-how about the code yet):
Checkout from launchpad bzr precise, but this does not matter.

1) plugins/screenshot/src/screenshot.cpp is extending the selection with the overlay, which at the end is to blame for the problem
(having the selected rectangle as overlay on the final screenshot).

If the "glRecti (...);" is commented out in "ShotScreen::glPaintOutput", the overlay is not drawn, only a rectangle around the selection, and the overlay is not seen on the screenshot. This could be a hacked solution to the problem towards having a "good" picture on the screenshot (however, that's not what is expected).

2) plugins/screenshot/src/screenshot.cpp is NOT explicitly taking care about removing the selection overlay. I don't know, which
piece of code does this, however, this seems the problem, since the code assumes that during " ShotScreen::paint" where the picture is taken using "glReadPixels", the overlay is already removed, which is not the case.

3) When debugging the thing using breakpoints in the states (ShotScreen::terminate, ShotScreen::paint) one sees that the break on terminate shows the selection high-lighted, the break on paint has no more hightlight, but the "glReadPixels" is still getting the bits with the hightlight on (I know that debugging X is dangerous wrt. results seen on the screen, I just report this for addional information).

Theory:

1) glReadPixels need some precondition (I tried glFlush without success) to get the current stuff read

2) glReadPixels and stuff around to safe the data need to be deferred until the selection is unhighlighted

Is there somebody with compiz knowhow, who could bring light into this issue?
cuK