| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3119
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | OpenGL |
|---|
| Summary: | Fl_Gl_Window switched off Aero in Windows 7 |
|---|
| Version: | 1.3-current |
|---|
| Created By: | suzukikojiro |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.5 (SVN: v13112) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | suzukikojiro
04:57 Aug 11, 2014 |
| In some environment, Fl_Gl_Window switched off Aero in Windows 7.
This problem may depend on graphics board or drivers.
The cause of this problem is the following.
Fl_Gl_Choice::find selects pixel format instead of ChoosePixelFormat in Win32.
It selects the pixel format which does not support composition, even though there are pixel formats supporting composition.
I would like to propose to add a config to select the pixel format supporting composition preferentially.
Sorry for my bad English.
Thank you. | |
| |
| #2 | AlbrechtS
05:11 Aug 15, 2014 |
| Set version to 1.3-current.
Set scope to 2 (operating system). | |
| |
| #3 | mliem
08:48 Jan 24, 2017 |
| I would like to push this issue up. I see that the current version (1.4.x-r12164) still doesn't fix this. The bug is a bit annoying, since the Aero interface gets switched off every time an FLTK application using OpenGL is launched. Since our software is meant to run in the background, it basically means users don't get to use the Aero interface anymore.
An easy fix would be to add a line like
if (!(pfd.dwFlags & PFD_SUPPORT_COMPOSITION)) continue;
at line 135 of Fl_Gl_Choice.cxx (for the fltk 1.3.3 release)
(just below
if (!(chosen_pfd.dwFlags & PFD_GENERIC_FORMAT) &&
(pfd.dwFlags & PFD_GENERIC_FORMAT)) continue;
)
Is this something that could be fixed in 1.4? | |
| |
| #4 | AlbrechtS
07:05 Jan 25, 2017 |
| Thanks for the heads-up (to both posters) and the patch instructions.
Yes, I think this can be fixed in 1.4, but there are some aspects that need to be taken care of:
(1) According to Microsoft's docs PFD_SUPPORT_COMPOSITION is not supported in older Windows versions including "... Windows 2000, ..., Windows XP, and Windows Server 2003".
Link: https://msdn.microsoft.com/en-us/library/cc231189.aspx
At least some more or less current versions of MinGW don't include the definition of PFD_SUPPORT_COMPOSITION, hence I added:
#if !defined(PFD_SUPPORT_COMPOSITION)
# define PFD_SUPPORT_COMPOSITION (0x8000)
#endif
right above:
Fl_Gl_Choice *Fl_WinAPI_Gl_Window_Driver::find(int m, const int *alistp)
This first part of a potential patch/fix is not necessary if PFD_SUPPORT_COMPOSITION is defined in your environment.
(2) The code in question has a specific order that seems to (try to) make sure that the "best" pixel format is selected. In an effort not to break existing user code I modified your instructions so that my test code now reads:
// see if better than the one we have already:
if (pixelformat) {
// offering non-generic rendering is better (read: hardware acceleration)
if (!(chosen_pfd.dwFlags & PFD_GENERIC_FORMAT) &&
(pfd.dwFlags & PFD_GENERIC_FORMAT)) continue;
// offering overlay is better:
else if (!(chosen_pfd.bReserved & 15) && (pfd.bReserved & 15)) {}
// otherwise prefer a format that supports composition (STR #3119) // added
else if ((chosen_pfd.dwFlags & PFD_SUPPORT_COMPOSITION) && // added
!(pfd.dwFlags & PFD_SUPPORT_COMPOSITION)) continue; // added
// otherwise more bit planes is better:
else if (chosen_pfd.cColorBits > pfd.cColorBits) continue;
else if (chosen_pfd.cDepthBits > pfd.cDepthBits) continue;
}
pixelformat = i;
chosen_pfd = pfd;
If in doubt, this order prefers GL Overlays over Composition (which is different than your proposal), but still may have effects on selection of color and depth bit sizes, resp. See three lines marked "// added".
This is code from FLTK 1.4 current (svn/git), src/Fl_Gl_Choice.cxx, ~lines 130-150 (line numbers are not exact since I added some test statements).
A full patch (including test statements) is attached (support_composition_v2.diff) and can be applied to FLTK 1.4 using 'patch -p1'.
Please report if this patch solves the issue for you (both). TIA.
Other users and devs that use OpenGL under Windows (7) are invited to test and report any issues before I commit anything.
PS: I can only test with Windows 10 since I don't have Windows 7/8/8.1. Under Windows 10 (notebook with embedded graphics) almost all pixel formats listed have the PFD_SUPPORT_COMPOSITION bit set and even the old code selected one with this property. Hence the issue seems to affect only Windows 7 (maybe also Win8/8.1). | |
| |
| #5 | AlbrechtS
07:13 Jan 25, 2017 |
| I'd appreciate if someone could test with the full patch and report the output under different Windows versions (please report the Windows version and related graphics information as well). Thanks. | |
| |
| #6 | mliem
08:06 Jan 25, 2017 |
| Hi, Thanks for replying and looking into this issue! I just tested the solution on a number of machines using the fltk gl_overlay example application. The fix seems to work fine! I checked the following machines:
Windows 7 Pro x64, Quadro K4000, issues with unpatched version, no issues with patched version
Windows 7 Pro x64, GTX 970, no issues using any fltk version
Windows 7 Pro x64, GTX 760, no issues using any fltk version
Windows 10 Pro x64, Quadro K4200, no issue using any fltk version | |
| |
| #7 | AlbrechtS
08:22 Jan 25, 2017 |
| Thanks for the quick report. So it seems that it really depends on the graphics adapter/driver (on Windows 7). | |
| |
| #8 | AlbrechtS
10:11 Oct 19, 2018 |
| I uploaded two patch files for FLTK 1.3.x and 1.4.0 resp.
support_composition_v3_r13071_1.3.diff and support_composition_v3_r13071_1.4.diff
The patches extend the solution with another small patch that prohibits selecting pixel formats with more than 32 color bits (8 bits per color). This has been reported in fltk.general at least twice to have an issue with certain graphics adapters that show too dim or too bright colors otherwise.
I also decided to commit the patch for FLTK 1.4 in the SVN repository (r 13072) so this issue can be considered fixed.
Note that I did intentionally NOT commit in branch-1.3 (yet). Please use the uploaded patch for FLTK 1.3, test, and confirm that this works for you. I'm not sure if we can use this for the next (and supposedly last) FLTK 1.3 release (1.3.5).
The more positive test results we get, the higher the probability that it will be included.
PS: you can enable debug output if you set the macro DEBUG_PFD to 1 in the patched source file. | |
| |
| #9 | AlbrechtS
10:12 Oct 19, 2018 |
| Fixed in Subversion repository. | |
| |
| #10 | AlbrechtS
10:32 Oct 19, 2018 |
| Links to related messages in Google Groups:
"Wrong pixel format (OpenGL) on notebooks with dual GPU on Windows":
https://groups.google.com/d/msg/fltkgeneral/u2Z895T_XSM/5xjD_P_lAAAJ
"Too bright with new nVidia driver"
https://groups.google.com/d/msg/fltkgeneral/CUZe39RA3QE/hxdg2zWjCQAJ
https://groups.google.com/d/msg/fltkgeneral/xSKIleljoCg/Ti4NbozgCAAJ | |
| |
| #11 | andek
14:14 Oct 20, 2018 |
| I can confirm that this latest patch works great for me, it removes the unwanted brightness after the nVidia driver update. | |
| |
| #12 | AlbrechtS
11:01 Nov 05, 2018 |
| Fixed in Subversion repository.
Fixed in branch-1.3 (1.3.5), svn r13112.
Previously fixed in branch-1.4 [git: master] (1.4.0), svn r13072.
Closing this STR now. Thanks to all contributors. | |
[ Return to Bugs & Features ]
|
| |
