We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1197

Summary: SDL_GL_ACCELERATED_VISUAL issues on Windows
Product: SDL Reporter: Matthias Bentrup <matthias.bentrup>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED DUPLICATE QA Contact: Sam Lantinga <slouken>
Severity: minor    
Priority: P2 CC: icculus, SDL, thilo
Version: HG 1.2   
Hardware: x86   
OS: Windows (All)   
Attachments: wgl acceleration patch

Description Matthias Bentrup 2011-05-02 03:40:00 UTC 
The current code always passes the WGL_ACCELERATION_ARB attribute with parameter WGL_FULL_ACCELERATION_ARB, and if the user specified the SDL_GL_ACCELERATED_VISUAL attribute it passes another WGL_ACCELERATION_ARB attribute with parameter either WGL_GENERIC_ACCELERATION_ARB or WGL_NO_ACCELERATION_ARB (which are both much slower than WGL_FULL_ACCELERATION_ARB) !

The attached patch fixes this so that the WGL_ACCELERATION_ARB is always set exactly once to either WGL_FULL_ACCELERATION_ARB or WGL_NO_ACCELERATION_ARB and chooses WGL_FULL_ACCELERATION_ARB if the SDL attribute is not set by the user.
Comment 1 Matthias Bentrup 2011-05-02 03:40:47 UTC 
Created attachment 609 [details]
wgl acceleration patch
Comment 2 Ryan C. Gordon 2011-08-21 09:05:44 UTC 
*** Bug 1281 has been marked as a duplicate of this bug. ***
Comment 3 Ryan C. Gordon 2011-08-21 09:14:22 UTC 
I'm marking this as a dupe, since Bug #1254 covers this issue for both 1.2 and 1.3.

--ryan.

*** This bug has been marked as a duplicate of bug 1254 ***
Comment 4 Thilo Schulz 2011-08-21 13:12:09 UTC 
I would also like to remark that this patch of yours introduces the behaviour of SDL-1.3, where WGL_FULL_ACCELERATION_ARB is added even if no explicit requirements on hardware acceleration were made. So you will prohibit libSDL from allowing the fallback to software rendering if for some reason hardware rendering is not available.

Maybe I am incorrect in my interpretation how choosing this pixelformat works. Read up on my thinking in my bug that Ryan marked to be the duplicate with this one. Ignore my first comment as it's wrong. Just read the second one and tell me what you think.
Comment 5 Matthias Bentrup 2011-08-22 00:40:02 UTC 
Hello Thilo,

your patch looks good. The semantics match the x11 implementation (0 = force accelerated mode, 1 = force software mode, -1 = allow both).
Comment 6 Ryan C. Gordon 2011-08-24 20:32:30 UTC 
I went with Thilo's patch.

--ryan.