Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi,
daenzer@debian.org (2009-04-28 at 1105.49 +0200):
> > I have been also trying other 3D apps, like Supertuxkart, and found
> > out the one running via PLib/SDL does not cause stacking issues, just
> > that in screenshots I get black pixels in zones covered by other
> > windows and the 3D content in non covered parts. STK from SVN does not
> > use SDL anymore... and the full bug appears.
>
> Does running the affected apps with
>
> XLIB_SKIP_ARGB_VISUALS=1
>
> work around the problem?
With that glxgears just prints:
---8<---
Error: couldn't get an RGB, Double-buffered visual
--->8---
Blender fails too:
---8<---
GHOST_WindowX11.cpp:177: X11 glxChooseVisual() failed for OpenGL, verify working openGL system!
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Resource id in failed request: 0xb6f9a020
Serial number of failed request: 29
Current serial number in output stream: 30
--->8---
But STK from SVN (the non Plib/SDL version) works, and windows over it
are not covered! It just reports:
---8<---
Level 1: No doublebuffering available.
--->8---
Screen captures of this STK show the 3D zone, with 2D windows over it
as plain black rectangles. FPS stats are even better than before by 10
or so frames (or maybe just coincidence... the important is that speed
is not a lot worse).
There is also a 2D app that causes black zones in similar fashion than
3D ones (its pixels which are covered by others appear as black). It
is a xterm with colour log and some settings in wm to put it below
others and non focusable. The interesting part is that if the covering
window is just 3D, the 3D info appears fine in the screenshots
(without frames, which are 2D and appear black, like in 2D over 3D
case). Maybe two bugs, or maybe all this "who can paint visible or
'screenshotable' pixel" is related somehow.
Thanks for all the patience.
GSR
Reply to: