| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #2663
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 2 - Specific to an operating system |
Subsystem: | OpenGL |
Summary: | OpenGL overlay bug on Windows 7 + Intel graphics |
Version: | 1.4-feature |
Created By: | rokan |
Assigned To: | Unassigned |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#1 | rokan 11:26 Jun 11, 2011 |
| Sometimes the opengl overlay is not redrawn when running on intel graphics on Windows 7 (and possibly Vista). You can see the bug running gl_overlay.exe from test directory: when you change number of vertices (or overlay vertices), the overlay either disappears or is nor redrawn. It is correctly redrawn only after you resize the window. Tested on 4 machines with Win7+IntelGr, all expose this behavior. ATI and nVidia work fine. The same applies for fltk-1.1.10 (all compiled with mingw)
After investigating the behavior I have found that ortho_context (which is only used to copy back buffer to front to emulate overlay) does not like repetitive setting of glReadBuffer(GL_BACK); glDrawBuffer(GL_FRONT); in which case overlay is not displayed. It also does not like glRasterPos2i(0,0). Apthough it seems like intel driver bug, there are so many win7+Intel boxes so I think we can not ignore the problem. I have tried many driver versions, all of them - including newest ones - have this problem.
My resolution to it is setting read/draw buffers within this static ortho_context only once when this context is created. As this context is used only for the back/front buffer copy and never changes (apart from viewport), the code should be correct (maybe even slightly faster). I have also commented out glRasterPos2i(0,0) again.
After that, everything works fine (tested on several win7 machines I have around - with Intel, ATI and nVidia chips, also on older XPs it works fine).
Here is the code change:
ORIGINAL CODE, Fl_Gl_Window.cxx staring at line 372:
if (orthoinit) ortho_context = fl_create_gl_context(this, g); fl_set_gl_context(this, ortho_context); if (orthoinit || !save_valid || ortho_window != this) { glDisable(GL_DEPTH_TEST); glReadBuffer(GL_BACK); glDrawBuffer(GL_FRONT); glLoadIdentity(); glViewport(0, 0, w(), h()); glOrtho(0, w(), 0, h(), -1, 1); glRasterPos2i(0,0); ortho_window = this; } glCopyPixels(0,0,w(),h(),GL_COLOR); make_current(); // set current context back to draw overlay
NEW CODE which suppresses the bug:
if (orthoinit){ ortho_context = fl_create_gl_context(this, g); fl_set_gl_context(this, ortho_context); glDisable(GL_DEPTH_TEST); glReadBuffer(GL_BACK); glDrawBuffer(GL_FRONT); glLoadIdentity(); }else fl_set_gl_context(this, ortho_context); if (orthoinit || !save_valid || ortho_window != this) { glViewport(0, 0, w(), h()); glOrtho(0, w(), 0, h(), -1, 1); // glRasterPos2i(0,0); // <- commenting it out again... ortho_window = this; } glCopyPixels(0,0,w(),h(),GL_COLOR); make_current(); // set current context back to draw overlay
Roman. | |
|
#2 | rokan 16:53 Jun 11, 2011 |
| Found a machine where the solution does not work, must look into it further... | |
|
#3 | AlbrechtS 05:59 Jun 14, 2011 |
| If this is a driver bug, can you work around it by changing graphics setup options? I had success by reducing "hardware acceleration" in the extended graphics setup (I can't tell the exact options, but I'll try to translate from my German Windows XP):
- right click on the desktop, select Properties - select Setup, select Extended - select Problem Handling - move the slider called "Hardware Acceleration" to a lower value - (maybe) reboot... | |
|
#4 | rokan 07:48 Jun 14, 2011 |
| This is windows 7 what gives me headache and it does not give me this option you have described (in English it is under Settings->Advanced->Troubleshoot). Windows XP works fine for me though - on very similar computer with the same graphics chip - 945. This is the one which gives me most problems (Intel Mobile 945 Express...) for which the newest drivers are from 2009 and do not work properly. The newer Intel chips have updated drivers (mostly from 2011) and still have problems with unmodified fltk, with the modification from above they work fine thought. I have tried various changes of the driver settings (flipping policy, triple buffering) and also switching on/off desktop transparency (Aero theme?), nothing seems to have an impact. | |
|
#5 | rokan2 11:45 Jul 21, 2012 |
| OK, I think i might be closer to the problem: It relay seems like a bug of Intel drivers with this old 9xx graphics. Unfortunately the drivers are are not updated any more and remain buggy.
The problem is that some of the current transformation matrices are not remembered and swapped with the context switch (also which is current matrix might not be remembered so glLoadIdentity could be eg applied on color matrix). That means that if you leave GL_MODELVIEW or GL_PROJECTION in non-non-identity state, after changing context using fl_set_gl_context() following call to glRasterPos2i(0,0) might not be invoked with identity transform matrices, might fell outside clipping region, become invalid and following glCopyPixels() does nothing.
Anyway, although this is a driver bug, there is plenty of 9xx Intel hardware still around. The code below (which solves the problem) might be little bit paranoiac but assures that, *BOTH* matrices (GL_PROJECTION and GL_MODELVIEW) are set to identity before call to glRasterPos2i()
glMatrixMode( GL_PROJECTION ); glLoadIdentity(); glMatrixMode( GL_MODELVIEW ); glLoadIdentity();
glViewport(0, 0, w(), h()); glOrtho(0, w(), 0, h(), -1, 1); glRasterPos2i(0,0);
Roman | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |