You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: 2.0.8 Reported for operating system, platform: Mac OS X (All), x86_64
Comments on the original bug report:
On 2018-09-25 21:50:47 +0000, David Ludwig wrote:
Created attachment 3313
sample code + Xcode project
When building + running a simple, LibSDL2 application on MacOS 10.14 (aka. Mojave) + Xcode 10, SDL_Render-driven content does not display, immediately. A window will be shown, however its content will be black. Strangely enough, moving the window causes content to be rendered.
This bug appears for me in both SDL 2.0.8, as well as SDL HG as of this writing (changeset 12220 / f10c21b0c0ef).
Source code for a sample application is attached. A full Xcode project is provided (however the bug has been observed outside of this sample project). To use the provided project:
extract the provided .tgz file
place a copy of SDL inside the extracted directory, SDL2-mojave-bug, such that SDL2-mojave-bug/SDL/include is a valid directory (amongst other SDL2 sub-dirs)
open the Xcode workspace, test-SDL.xcworkspace (located inside the SDL2-mojave-bug directory)
build and run the "test-sdl" target. This will build BOTH test-sdl, and the copy of SDL at SDL2-mojave-bug/SDL/
To show the bug, on a system with macOS 10.14/Mojave installed, use Xcode 10 to build + run the provided application. A green window should appear, however a black one is displayed. Moving the window will cause green content to be displayed.
On 2018-09-26 03:18:41 +0000, Sam Lantinga wrote:
Hey Ryan, I think this is related to the other e-mail chain we had going... what was the resolution of that?
On 2018-09-26 16:32:28 +0000, David Ludwig wrote:
Created attachment 3315
a non-fix, probably
This is a very hack-ish patch, which I assume should not get committed (to hg.libsdl.org/SDL, etc.), however it does "fix" the bug for me. The patch was applied to hg at changeset 12220:f10c21b0c0ef
On 2018-09-26 18:25:23 +0000, Michael Schwartz wrote:
I have the issue, too.
Previously working program shows black window until I click on the window after I upgraded to Mojave.
Before the upgrade, the window contents rendered without forcing me to click on it first.
On 2018-09-26 18:32:31 +0000, Ryan C. Gordon wrote:
*** Bug 4274 has been marked as a duplicate of this bug. ***
On 2018-09-26 19:15:32 +0000, David Ludwig wrote:
Resizing SDL's window will, also, cause rendered content to start displaying, alternatively to moving it.
On 2018-09-27 00:20:59 +0000, Ryan C. Gordon wrote:
This pushes a single update to the GL context at a point when we know everything is set up (when the window becomes key), so performance stays good and it's safe to do this here in any case. I don't know if this is the correct thing to do, but it does appear to solve the issue in a reasonable way.
That said, there might be a better event to use for forcing the GL context update.
--ryan.
On 2018-09-27 00:34:47 +0000, David Ludwig wrote:
Ryan, I can confirm that your patch works for me.
I'm still confused as to -why- this occurs, but am glad to at least see a fix staged for the next SDL release. :-)
On 2018-09-27 01:05:17 +0000, Ryan C. Gordon wrote:
I'm still confused as to -why- this occurs, but am glad to at least see a
fix staged for the next SDL release. :-)
My guess is that we are calling [NSOpenGLContext update] too early; the context throws it away or whatever because something is still being constructed, and since we set a dirty flag, we never call update again, except when we get resize/move events, as the OS requests. I just plugged in an update call when the window becomes key. There is likely an earlier point where we can do this. It might be that the runloop has to be going first, and we're way past that point by the time the window becomes key. I don't know.
But it's worth noting that the same program built with Xcode 9 works, so there's at least a fallback for older apps at the OS level, and an intentional breaking in newer versions.
--ryan.
On 2018-09-27 01:50:04 +0000, Ryan C. Gordon wrote:
...thinks we should be tracking this on NSViewGlobalFrameDidChangeNotification, fwiw.
--ryan.
On 2018-09-27 12:57:41 +0000, Daniel Bokser wrote:
Hi Ryan,
Thank you for the patch! Unfortunately, it does not seem to work for my application. However, I confirmed it works in the simplest case (open a window and renderer and do a RenderClear). The fix/workaround presented by Gred here (https://discourse.libsdl.org/t/macos-10-14-mojave-issues/25060/2), in addition to your fix, worked for me:
Same problem for me. As a temporary solution I’ve added
[NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(scheduleUpdate) userInfo:nil repeats:NO];
at the end of - (void)setWindow:(SDL_Window *)newWindow method in video/cocoa/SDL_cocoaopengl.m
I am currently trying to narrow down what about my application doesn’t work with your fix versus the simple case where it does work.
Please let me know what you think. Thanks for your work!
-Daniel
On 2018-09-28 03:07:04 +0000, Indiana Kernick wrote:
I guess the long-term solution to any OpenGL related issues on MacOS would be to use Metal instead. Is it possible that since Apple has depreciated OpenGL, it might start slowly breaking in subtle ways, creating many issues similar to this one? Is the metal renderer still actively developed?
On 2018-09-28 06:38:54 +0000, Ryan C. Gordon wrote:
(In reply to Indi from comment # 11)
Is it possible that since Apple has depreciated
OpenGL, it might start slowly breaking in subtle ways, creating many issues
similar to this one?
Yes.
Is the metal renderer still actively developed?
Yes.
On 2018-09-30 17:27:54 +0000, Alex Szpakowski wrote:
With the current fix in hg, I still have the problem if I double-click an app to open it. If I run the app's executable directly from a terminal, it works as expected.
On 2018-10-01 01:20:38 +0000, Ryan C. Gordon wrote:
(In reply to Alex Szpakowski from comment # 13)
With the current fix in hg, I still have the problem if I double-click an
app to open it. If I run the app's executable directly from a terminal, it
works as expected.
I think we have the right solution, firing on the wrong event. Apple docs (old enough that the pages still use the 10.0 "aqua" theme) say you should call -[NSOpenGLContext update] in a NSViewGlobalFrameDidChangeNotification handler, but I couldn't get this event to fire (disclaimer: I probably screwed up adding it to an observer).
I get a black screen.. If I move the window, the menu appears briefly
with the animating Q logo, but then the application freezes (less than
a second later) inside a call to SDL_GL_SwapWindow. Strangely doesn't
happen with the prebuilt QS binary from sourceforge.
The prebuilt QS binaries he refers to were cross-built on a i686 CentOS
6.10 Linux setup using gcc-4.2.1 (Apple v5666) against OS X 10.6 sdk.
It should be noted that QS does not use SDL_render, but uses OpenGL
directly.
On 2018-10-02 01:18:50 +0000, Alex Szpakowski wrote:
(In reply to Ryan C. Gordon from comment # 14)
I think we have the right solution, firing on the wrong event. Apple docs
(old enough that the pages still use the 10.0 "aqua" theme) say you should
call -[NSOpenGLContext update] in a NSViewGlobalFrameDidChangeNotification
handler, but I couldn't get this event to fire (disclaimer: I probably
screwed up adding it to an observer).
--ryan.
I got it to fire... sometimes? It was firing when double-clicking my app to open it earlier today, but now it's not happening for me even though I haven't changed any code.
(Unrelated - I think - to this specific issue, but on the topic of issues with macOS 10.14...) I'm also getting weird behaviour where application:openFile: and applicationDidFinishLaunching: are sometimes called after some PumpEvents calls, rather than in video init, if I drag a file onto my app to open it... it's very strange, I feel like there are some nasty bugs inside Cocoa in 10.14.
On 2018-10-08 15:11:09 +0000, Alex Szpakowski wrote:
Windows in apps linked against the macOS 10.14 SDK are displayed using
Core Animation when the app is running in macOS 10.14. This doesn’t
mean that all views are layer-backed; rather, it means that all views
are either layer-backed or draw into a shared layer with other layers.
I tried adding a ScheduleContextUpdates call in SDLView's drawRect implementation (after the NSRectFill call) and it fixed the black screen issue in all situations I've tested so far, but it scales up the view's contents if highdpi is disabled on my computer. With highdpi enabled it works fine. I guess the view (@1x) is sharing the window's layer (@2x), or something.
On 2018-10-08 20:21:01 +0000, Alex Szpakowski wrote:
Reverting the change to draw a black background with drawRect ( https://hg.libsdl.org/SDL/rev/64ae77236054 ) seems to resolve all the black screen issues, as long as the [window setBackgroundColor] call removed in that commit is there.
Unfortunately with the macOS dark theme and NSColor.clearColor (via https://twitter.com/slime73/status/923304862196142080 ) the title bar doesn't look exactly the same as with no setBackgroundColor call, but it's very close.
On 2018-10-08 20:27:48 +0000, Alex Szpakowski wrote:
Without the setBackgroundColor call, non-highdpi windows also seem to use a different form of upscaling for their content (bilinear filtering instead of point filtering) compared to previous macOS versions. With the setBackgroundColor call it behaves the same as macOS 10.13 and older.
I'm not sure why that's the case, but maybe that tidbit will be useful information to someone.
On 2018-10-09 03:28:51 +0000, Ryan C. Gordon wrote:
Created attachment 3353
This appears to fix it.
Going off what Alex said and digging into that document from Apple, this patch fixes it 100% here, but I have no idea what the ramifications are.
Basically this just makes sure the SDLView gets its own CoreAnimation layer. There might be better ways to do this (and that ES2/EGL #ifdef below it might be obsolete with this patch, or might do the same thing with more backwards compatibility). The Metal renderer has continued to work into Mojave, regardless, and I believe that's because it has always lived in its own layer, as the Metal API has always required that.
(This patch still needed the GL context update fix that is already in revision control.)
On 2018-10-09 03:31:28 +0000, Ryan C. Gordon wrote:
(In reply to Ryan C. Gordon from comment # 20)
Going off what Alex said and digging into that document from Apple, this
patch fixes it 100% here, but I have no idea what the ramifications are.
(Since wantsUpdateLayer tells Cocoa to not call drawRect, naturally you get that flash of white when the window is created. I know we all love that bug.)
--ryan.
On 2018-10-09 03:50:29 +0000, Ryan C. Gordon wrote:
Created attachment 3354
Fix the GL context and make the layer black by default
(In reply to Ryan C. Gordon from comment # 21)
(Since wantsUpdateLayer tells Cocoa to not call drawRect, naturally you get
that flash of white when the window is created. I know we all love that bug.)
Actually, that's an easy fix, now that I read some random slide deck from WWDC in 2012. :)
We still need to decide:
a) if I'm totally wrong about all of this.
b) if that ES2/EGL code can be deleted.
c) if this conflicts with Metal in any way (the Metal renderer still works, but are we generating an extra wasted layer or anything?)
d) if any of this needs backwards compat for older OS releases (does drawRect need to remain, etc? What's even our minimum supported macOS at this point?)
--ryan.
On 2018-10-10 14:07:50 +0000, Ryan C. Gordon wrote:
Shoot, this still gives me a too-large context if I do fullscreen_desktop.
Using "./testsprite2 --fullscreen-desktop", it looks like I get the bottom-left corner of the context (single green diagonal line goes across whole screen instead of crossing another in the center)...so the framebuffer ended up being 2x the correct size.
Rendering within that framebuffer appears to be otherwise correct (smiley faces aren't twice as big).
Setting layer.contentsScale = 1.0f doesn't fix it, layer.bounds appear to be correct.
So annoying!
--ryan.
On 2018-10-18 16:35:46 +0000, Ryan C. Gordon wrote:
(In reply to Ryan C. Gordon from comment # 23)
Shoot, this still gives me a too-large context if I do fullscreen_desktop.
Okay, it's not the framebuffer size, it's that SDL_GL_GetDrawableSize() is wrong when fullscreen on Mojave, which makes testsprite2 call glViewport() incorrectly.
The GL context update happens in updateLayer now, instead of when the window becomes key, and that seems to fix all the corner cases, too.
We still need to test this on the oldest supported macOS (10.6?), but presumably this should still use the old interfaces there and the new code on 10.8+ without drama...knock on wood.
--ryan.
On 2018-10-18 20:29:51 +0000, Ryan C. Gordon wrote:
We still need to test this on the oldest supported macOS (10.6?), but
presumably this should still use the old interfaces there and the new code
on 10.8+ without drama...knock on wood.
Just tried this on Mac OS X 10.7 (in a virtual machine) and testsprite2 and testgl2 both work there, built with Xcode 10 and -mmacos-version-min=10.7
(and AppKit manually linked as a weak framework, but that's a separate bug, I guess.)
I'm marking this FIXED, but please test your games with the latest in revision control and report problems here!
--ryan.
On 2018-10-19 02:25:40 +0000, Daniel Bokser wrote:
This fix works for me for the black screen. Thank you!
Unfortunately, this does not fix another Mojave issue I opened a while ago (as I hoped it would): https://bugzilla.libsdl.org/show_bug.cgi?id=4278. It is still in a NEW state so wasn't sure if it was missed.
Since this other issue is a Mojave issue, I'd figure I post it here. Apologies, if I shouldn't have.
On 2018-10-28 17:15:02 +0000, Ryan C. Gordon wrote:
*** Bug 4327 has been marked as a duplicate of this bug. ***
On 2019-08-22 11:20:08 +0000, Ozkan Sezer wrote:
(In reply to Ryan C. Gordon from comment # 24)
[...]
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
This appears to fix it. (file_4272.txt, text/plain, 2018-10-09 03:28:51 +0000, 717 bytes)Reported in version: 2.0.8
Reported for operating system, platform: Mac OS X (All), x86_64
Comments on the original bug report:
On 2018-09-25 21:50:47 +0000, David Ludwig wrote:
On 2018-09-26 03:18:41 +0000, Sam Lantinga wrote:
On 2018-09-26 16:32:28 +0000, David Ludwig wrote:
On 2018-09-26 18:25:23 +0000, Michael Schwartz wrote:
On 2018-09-26 18:32:31 +0000, Ryan C. Gordon wrote:
On 2018-09-26 19:15:32 +0000, David Ludwig wrote:
On 2018-09-27 00:20:59 +0000, Ryan C. Gordon wrote:
On 2018-09-27 00:34:47 +0000, David Ludwig wrote:
On 2018-09-27 01:05:17 +0000, Ryan C. Gordon wrote:
On 2018-09-27 01:50:04 +0000, Ryan C. Gordon wrote:
On 2018-09-27 12:57:41 +0000, Daniel Bokser wrote:
On 2018-09-28 03:07:04 +0000, Indiana Kernick wrote:
On 2018-09-28 06:38:54 +0000, Ryan C. Gordon wrote:
On 2018-09-30 17:27:54 +0000, Alex Szpakowski wrote:
On 2018-10-01 01:20:38 +0000, Ryan C. Gordon wrote:
On 2018-10-01 09:01:11 +0000, Ozkan Sezer wrote:
On 2018-10-02 01:18:50 +0000, Alex Szpakowski wrote:
On 2018-10-08 15:11:09 +0000, Alex Szpakowski wrote:
On 2018-10-08 20:21:01 +0000, Alex Szpakowski wrote:
On 2018-10-08 20:27:48 +0000, Alex Szpakowski wrote:
On 2018-10-09 03:28:51 +0000, Ryan C. Gordon wrote:
On 2018-10-09 03:31:28 +0000, Ryan C. Gordon wrote:
On 2018-10-09 03:50:29 +0000, Ryan C. Gordon wrote:
On 2018-10-10 14:07:50 +0000, Ryan C. Gordon wrote:
On 2018-10-18 16:35:46 +0000, Ryan C. Gordon wrote:
On 2018-10-18 20:29:51 +0000, Ryan C. Gordon wrote:
On 2018-10-19 02:25:40 +0000, Daniel Bokser wrote:
On 2018-10-28 17:15:02 +0000, Ryan C. Gordon wrote:
On 2019-08-22 11:20:08 +0000, Ozkan Sezer wrote:
On 2019-09-04 07:59:36 +0000, Ozkan Sezer wrote:
The text was updated successfully, but these errors were encountered: