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 4810 - macOS 10.15: window doesn't get cleared to black, and GL content in non-highdpi windows is scaled until window is moved
Summary: macOS 10.15: window doesn't get cleared to black, and GL content in non-highd...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86_64 macOS 10.15
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-27 22:53 UTC by Alex Szpakowski
Modified: 2019-10-14 03:53 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Szpakowski 2019-09-27 22:53:25 UTC
It looks like macOS 10.15 has some fun new behaviour that we'll need to address.

On my computer (with the latest 10.15 public beta and the latest release version of Xcode 11), [SDLView updateLayer] is not called by the OS when the window/GL context is created. [SDLView drawRect:] *is* called, however the NSRectFill call doesn't seem to have any effect so the window contents is the default OS color (white when the OS is in light mode) for a frame, instead of black.

Additionally, when the window isn't created with highdpi mode, the contents of my OpenGL framebuffer are in the bottom left of the window and scaled down by 2x. If I move the window it updates so the contents are in the right position and scaled correctly. If I comment out the ScheduleContextUpdates() call in [Cocoa_WindowListener windowDidMove:], it does not update the contents to the right position/scale when I move the window.
Comment 1 Alex Szpakowski 2019-10-14 00:41:01 UTC
I think https://hg.libsdl.org/SDL/rev/46b094f7d20e should fix the scaling issue.
Comment 2 Alex Szpakowski 2019-10-14 03:14:51 UTC
I think I understand what's going on with drawRect+NSRectFill now.

I get some "CGContextSetFillColorWithColor: invalid context 0x0" messages printed during startup, macOS lets me see a backtrace of it. The stack in the backtrace includes [SDLView drawRect:] and [_NSOpenGLViewBackingLayer display].

So it looks like macOS 10.15 is using some NSOpenGLView code under the hood when a NSOpenGLContext is attached to a regular NSView, and it's hiding the fact that there's a layer by attempting to emulate the old behaviour - but without a real NSGraphicsContext active, since I guess they just expected apps to only use direct OpenGL calls in drawRect in this situation.

I'll try to think of a good solution for that.
Comment 3 Alex Szpakowski 2019-10-14 03:53:07 UTC
https://hg.libsdl.org/SDL/rev/065b94926987 fixes it for me.