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 2555 - [OS X] SDL_SetWindowBrightness does not persist when entering fullscreen
Summary: [OS X] SDL_SetWindowBrightness does not persist when entering fullscreen
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86 Other
: P2 normal
Assignee: Alex Szpakowski
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-19 21:29 UTC by Eric Wasylishen
Modified: 2017-08-19 03:42 UTC (History)
1 user (show)

See Also:

Attachments
patches SDL test programs to accept a --brightness flag (2.37 KB, patch)
2014-05-19 21:29 UTC, Eric Wasylishen 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Wasylishen 2014-05-19 21:29:39 UTC 
Created attachment 1656 [details]
patches SDL test programs to accept a --brightness flag

Entering fullscreen mode with SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN) when you previously set a custom brightness level with SDL_SetWindowBrightness() resets the window brightness to the default.

Steps to reproduce:
- the attached patch adds a --brightness flag to the test programs
- launch testdraw2 with "--brightness 0.25". The window should be very dark.
- press Control+Enter to enter fullscreen.

Expected: the low brightness level persists in fullscreen mode
Observed: the demo graphics have reverted to regular brightness in fullscreen mode

Tested on Mac OS X 10.9.2 with the latest sdl2 from hg.
Comment 1 Eric Wasylishen 2014-05-31 18:50:45 UTC 
It appears that the OS resets the display gamma to the default around 2 seconds after we do a display mode change. I verified that it's not SDL erroneously resetting the gamma.

Also, simply calling Cocoa_SetWindowGammaRamp(_this, window, window->gamma); at the end of Cocoa_SetWindowFullscreen doesn't fix the problem.
Comment 2 Daniel Gibson 2016-05-27 23:57:27 UTC 
As one can probably expect from Eric's observations, this also affects SDL_SetWindowGammaRamp() of course.

We had this issue reported for Yamagi Quake2 (https://github.com/yquake2/yquake2/issues/134), just so you know more people are affected by this ;-)

Any idea why OSX does this?

Any ideas/plans for a workaround in SDL? Would probably be ugly as hell to re-set the gamma settings 2 seconds (is it even always exactly two seconds?) after changing resolution or switching from/to fullscreen..
Comment 3 Eric Wasylishen 2016-05-28 21:29:47 UTC 
I haven't looked at this in 2 years since reporting, but in Quakespasm we gave up on the SDL brightness API's and switched to doing gamma in a postprocessing fragment shader, only falling back to SDL_SetWindowBrightness on OpenGL 1.x. This has the added benefit of not messing up the gamma of your entire monitor when running in a window.

I think these SDL_SetWindowBrightness/GammaRamp API's should be deprecated if it's not possible to fix them.
Comment 4 Alex Szpakowski 2017-08-19 03:42:08 UTC 
> I think these SDL_SetWindowBrightness/GammaRamp API's should be deprecated if it's not possible to fix them.

Agreed. I also remember getting annoyed at some of Valve's games in macOS for setting the display gamma via window brightness APIs and causing everything to be much more blue than how I had calibrated my display. (Not sure if they still do this or not, it was a few years ago.)

I think window brightness / gamma APIs made a lot more sense in the era before shaders were ubiquitous, but since they can't even work properly and shaders can easily replace them these days, I'd be happy if they were gone.