| 2011-05-27 23:28:52 |
Rena Kunisaki |
description |
Binary package hint: compiz
This is similar to Bug #745839 (for a while I thought that's what it was), but not quite the same issue. Compiz renders everything to a single, giant OpenGL window that covers the entire display area. If your display area is larger than your video card's maximum *framebuffer* size (not *texture* size as in Bug #745839), OpenGL fails to initialize.
Compiz does not detect this failure, and so still covers your screen with this window which now does not have an OpenGL context bound to it. As a result, all drawing operations fail. The window never gets redrawn, so it keeps displaying whatever happened to be in the block of video memory allocated to it (which in my case is usually a corrupted version of the desktop wallpaper). The apparent effect is that all you can see is a screenfull of garbage; the cursor still changes and interacts with windows, but they aren't visible.
This problem isn't solved by breaking windows into multiple small textures, since the issue isn't the size of the window textures but the size of the OpenGL framebuffer they're being drawn into. The only workaround I can think of would be to create multiple OpenGL windows (probably one per monitor) and split the drawing between them. (Hopefully it's possible to share textures between multiple OpenGL windows; otherwise it might be necessary to forbid a window from ever spanning across multiple screens.)
This issue is the cause of the error message: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
The same can be seen with other programs, e.g.: glxgears --geometry 3000x1000+0+0
This displays the same error message and the same window full of garbage (at least for one frame before glxgears resizes its window for some reason). |
Binary package hint: compiz
This is similar to Bug #745839 (for a while I thought that's what it was), but not quite the same issue. Compiz renders everything to a single, giant OpenGL window that covers the entire display area. If your display area is larger than your video card's maximum *framebuffer* size (not *texture* size as in Bug #745839), OpenGL fails to initialize.
Compiz does not detect this failure, and so still covers your screen with this window which now does not have an OpenGL context bound to it. As a result, all drawing operations fail. The window never gets redrawn, so it keeps displaying whatever happened to be in the block of video memory allocated to it (which in my case is usually a corrupted version of the desktop wallpaper). The apparent effect is that all you can see is a screenfull of garbage; the cursor still changes and interacts with windows, but they aren't visible.
This problem isn't solved by breaking windows into multiple small textures, since the issue isn't the size of the window textures but the size of the OpenGL framebuffer they're being drawn into. The only workaround I can think of would be to create multiple OpenGL windows (probably one per monitor) and split the drawing between them. (Hopefully it's possible to share textures between multiple OpenGL windows; otherwise it might be necessary to forbid a window from ever spanning across multiple screens.)
This issue is the cause of the error message: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
The same can be seen with other programs, e.g.: glxgears --geometry 3000x1000+0+0
This displays the same error message and the same window full of garbage (at least for one frame before glxgears resizes its window for some reason).
Since the corrupted display is really just a window covering everything, it's still possible to kill Compiz (by blindly clicking or typing or using another terminal) and get the display working again, but for novice users the apparent effect would be that they simply can't see any windows. |
|
