|
1f276a51
|
2022-07-26T13:30:59
|
|
Fix Main Thread Checker warning on macOS
Cache off NSWindow's windowNumber in SDL_WindowData on setup and use that in `Cocoa_SendWakeupEvent` to prevent accessing windowNumber off the main thread.
|
|
218c3dbb
|
2022-07-26T14:45:26
|
|
cocoa: Don't crash if moving a message box created before SDL_Init.
Fixes #5928.
|
|
20a76b0e
|
2022-07-25T23:06:58
|
|
video: removed unused devindex argument from bootstrap's create method.
|
|
4d665017
|
2022-07-24T18:04:26
|
|
Fixed building with 10.9 SDK
Fixes https://github.com/libsdl-org/SDL/issues/5954
|
|
6bcde52d
|
2022-07-24T20:19:16
|
|
Further adjust implementation of `Cocoa_GetWindowDisplayIndex`
As discussed in PR review, there may be an off-chance that the index
returned doesn't match up with SDL's display indexing.
This change ensures that the indices match and adds a safety check for
off-screen windows.
|
|
ce8aae14
|
2022-07-13T15:01:55
|
|
Fix `Cocoa_GetWindowDisplayIndex` failing and causing a catastrophic crash
With the introduction of this function, it is possible that for certain
monitor and window configurations, creating an SDL window will cause a
native crash.
```
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000050
Exception Codes: 0x0000000000000001, 0x0000000000000050
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [56627]
VM Region Info: 0x50 is not in any region. Bytes before following region: 140737486737328
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
VM_ALLOCATE 7fffffe75000-7fffffe76000 [ 4K] r-x/r-x SM=ALI
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libSDL2.dylib 0x10247f665 SDL_UpdateFullscreenMode + 357
1 libSDL2.dylib 0x10247ec70 SDL_CreateWindow_REAL + 1504
2 ??? 0x111262de8 ???
3 ??? 0x110c39fff ???
4 libcoreclr.dylib 0x101fdf2a9 CallDescrWorkerInternal + 124
```
Tracking thread from our end: https://github.com/ppy/osu-framework/issues/5190
Regressed with: https://github.com/libsdl-org/SDL/pull/5573
In testing, the window would not find a valid screen if created
"hanging" off a primary display with a secondary display below it. In
checking why this was the case, the `display_centre` was being
calculated with a negative y origin, causing a final negative value
falling outside all display bounds:
```
SDL error log [debug]: display_centre.y = -1296 + 1296 / 2
SDL error log [debug]: Display rect 0: 0 0 2560 1440
SDL error log [debug]: Display rect 1: 2560 -625 1080 2560
SDL error log [debug]: Display rect 2: 0 1440 1728 1296
```
The method that was being used to find the current window using the frame
origin/size seems unreliable, so I have opted to replace it with with a
tried method (https://stackoverflow.com/a/40891902).
Initial testing shows that this works with non-standard DPI screens, but
further testing would be appreciated (cc @sezero / @misl6 from the
original PR thread).
|
|
cef1514b
|
2022-07-17T09:07:04
|
|
Fixed some Xcode warnings
|
|
b085c182
|
2022-07-04T16:38:05
|
|
make SDL_SetTextInputRect take a pointer to const
The documentation doesn't state that the argument is ever modified,
and no implementation does so currently.
This is a non-breaking change to guarantee as much to callers.
|
|
6c536afd
|
2022-06-27T15:43:17
|
|
Fix C89 declaration for macOS modules.
Since Clang 14, `-Wdeclaration-after-statement` is enforced on every
standard.
|
|
412ceb84
|
2022-05-24T16:27:54
|
|
video: Only check major version in SDL_GetWindowWMInfo
Since #5602, SDL is intended to have the same ABI across the whole
major-version 2 cycle, so we should not check that the minor version
matches the one that was used to compile an application.
There are two checks that could make sense here.
The first check is that the major version matches the expected major
version. This is usually unnecessary and is not usually done (if we're
calling into the wrong library we'll likely crash anyway), but since we
have the information, we might as well continue to use it.
The second check is whether the version provided by the caller is
equal to or greater than a threshold version at which additional fields
were added to the struct. If it is, we should populate those fields;
if it is not, then we cannot. This is only useful on platforms where
additional fields have genuinely been added during the lifetime of
SDL 2, like Windows and DirectFB (but not X11).
This commit changes the first check to be consistent about only looking
at the minor version, while leaving the second check using SDL_VERSIONNUM
(which will be removed or widened in SDL 3, but it's fine for now).
Resolves: https://github.com/libsdl-org/SDL/issues/5711
Fixes: cd7c2f1 "Switch versioning scheme to be the same as GLib and Flatpak"
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
56665e1d
|
2022-05-17T12:50:13
|
|
cocoa: Try to use better system cursors.
These try to pull from the .pdf files that are installed with
macOS, which fit our needs better, and fall back to the most
reasonable defaults available from NSCursor if we can't load
them.
Since these are installed under /System, they should be sandbox
accessible, and if this totally fails, it should still go on,
albeit with a less good cursor.
Reference Issue #2123.
|
|
e9c7b519
|
2022-05-16T21:03:41
|
|
macOS: Fix reference counts of internal window data.
Fixes crashes when destroying or recreating a window (#5664).
|
|
f871c178
|
2022-05-10T17:32:24
|
|
macOS: remove dead code for supporting 10.6 at runtime.
|
|
ec8fa577
|
2022-05-07T21:57:23
|
|
macOS: always use Objective-C ARC (automatic ref counting).
Change Cocoa SDL_VideoData and SDL_WindowData implementations from C structs to Objective-C objects, since bridging between C and ObjC is easier that way.
|
|
7e636b03
|
2022-04-29T10:16:14
|
|
Removed log message length limitation for Apple platforms
This works in conjunction with https://github.com/libsdl-org/SDL/pull/5584
|
|
b293888c
|
2022-04-26T19:44:34
|
|
Fixes an issue introduced via #5573 when building for i686
|
|
795744fc
|
2022-01-07T10:11:46
|
|
Turn off relative mouse before window checks as well
|
|
e2d268a3
|
2022-01-06T23:42:44
|
|
SDL_cocoamouse.m: SetRelativeMouseMode even if out of focus
Should fix #3087
|
|
76afb858
|
2022-04-25T10:35:56
|
|
Introduces Cocoa_GetWindowDisplayIndex. This enable a proper management for dpi when switching between retina and non-retina displays.
|
|
8f964576
|
2022-03-19T11:01:55
|
|
Fixed parameter operation ordering for ease of reading
|
|
0517b61e
|
2022-03-19T11:00:00
|
|
Relative mouse mode is tied to the window with keyboard focus
This isn't obvious, but makes sense when thinking about how games actually use it. This is also in line with how Windows mouse relative mode is implemented.
Fixes https://github.com/libsdl-org/SDL/issues/5340
|
|
a164c9d2
|
2022-01-04T10:43:34
|
|
SDL_cocoawindow.m: update fullscreen toggle when SDL_SetWindowResizable called
|
|
ea0bca57
|
2022-01-11T14:56:56
|
|
SDL_cocoamodes.m: fix build against older SDKs.
Fixes https://github.com/libsdl-org/SDL/issues/5208
|
|
4b38d4c9
|
2022-01-07T12:37:28
|
|
Leave the Metal view active on the window when recreating the Metal renderer
Fixes https://github.com/libsdl-org/SDL/issues/5140
Also move the metal tag definition to SDL_syswm.h so it can be used by applications
|
|
120c76c8
|
2022-01-03T09:40:00
|
|
Updated copyright for 2022
|
|
4b112620
|
2022-01-02T19:11:50
|
|
SDL_cocoamodes.m (Cocoa_GetDisplayDPI): fix build using older toolchains
Fixes https://github.com/libsdl-org/SDL/issues/5162
|
|
6a7b6380
|
2021-12-28T12:07:56
|
|
Fix macOS cursor jumping to corner on first titlebar click
|
|
a35a7d25
|
2021-12-25T05:00:26
|
|
Fix SigSegV from displayInfoInvalidate when changing resolution
|
|
1c41b535
|
2021-12-25T03:47:59
|
|
macOS: Calculate correct DPI by not using backingScaleFactor
|
|
66fbf00e
|
2021-12-09T10:40:18
|
|
Temporarily ignore gl_config.driver_loaded check in Cocoa_GLES_SetupWindow.
|
|
da0f76de
|
2021-12-07T00:38:46
|
|
cocoa: Don't round scroll deltas from trackpads
Rounding the scroll deltas from trackpads causes jerky scrolling behavior
by artificially amplifying the effects of very small scroll movements.
We should only round events from devices with discrete scroll wheels,
because we know the smallest unit of movement there is a single tick.
|
|
ceb9e9a8
|
2021-11-21T00:21:41
|
|
cocoa: Removed a debug printf call.
|
|
18715acb
|
2021-11-21T00:14:18
|
|
cocoa: Position non-left mouse button events in background windows correctly.
Fixes #4828.
|
|
cc094f4d
|
2021-11-14T20:15:48
|
|
Fixed building with the macOS 10.8 SDK
|
|
1cd3e837
|
2021-11-14T15:51:38
|
|
cocoa: Fix abort on touch event types without a subtype
macOS 10.6 has some touch NSEvents which do not have a subtype
(Begin/EndGesture, Magnify, Rotate, Swipe) and cause an uncaught
exception which triggers SIGABRT and the program exits.
As it is, none of the macOS 10.6 touch events are detected as a
trackpad (including Gesture due to using different subtypes).
|
|
074e613b
|
2021-11-12T03:03:56
|
|
Fixed typo
|
|
35d90f17
|
2021-11-12T03:00:57
|
|
Better implementation of SDL_SetWindowMouseGrab() and SDL_SetWindowMouseRect() on macOS
|
|
fd79607e
|
2021-11-08T21:34:48
|
|
Added SDL_GetWindowMouseRect()
Also guarantee that we won't get mouse movement outside the confining area, even if the OS implementation allows it (e.g. macOS)
|
|
4db546b0
|
2021-11-08T20:35:12
|
|
Implemented SDL_SetWindowMouseRect() on macOS
|
|
ba4ef461
|
2021-10-23T15:28:13
|
|
macOS: Fix implicit integer downcast warnings
|
|
19dee1cd
|
2021-10-22T06:37:20
|
|
Add SDL_GetWindowICCProfile(). (#4314)
* Add SDL_GetWindowICCProfile
* Add new SDL display events
* Implement ICC profile change event for macOS
* Implement ICC profile notification for Windows
* Fix SDL_GetWindowICCProfile() for X11
* Fix compile errors
|
|
d9c44b65
|
2021-10-19T10:49:17
|
|
Allow Cocoa_VideoInit to succeed when current display mode has invalid flags
This fixes a specific issue seen on macOS 10.14.6 where a DELL E248WFP
Display connected to a 2014 Mac Mini with a scaled 1920x1080 resolution
selected and SDL_Init(SDL_INIT_VIDEO) failed with the error: "The video
driver did not add any displays".
The underlying cause was that the current 1080p display mode did not
have the flag kDisplayModeSafeFlag, the check for which was added in
a963e36, with the idea that certain display modes should not be
candidates for switching to in fullscreen exclusive mode. That may well
be the right thing to do for filtering down a list of candidate modes,
but it doesn't pay to be so picky about the current mode. After all,
this current mode was set by System Preferences, the picture does appear
correctly on screen, and other non-SDL based applications launch and run
correctly in this mode.
Therefore the fix is to have GetDisplayMode only filter out a mode based
on flags if it's part of a candidate list, but if it's the current mode
and it can possibly be converted to an SDL_DisplayMode, do so.
|
|
6f684f67
|
2021-07-29T18:20:36
|
|
cocoa: Add keyboard grab support
CGSSetGlobalHotKeyOperatingMode() is not a public API, so we will only
compile this in if SDL_MAC_NO_SANDBOX=1 is defined during compilation.
|
|
51c61d7c
|
2021-07-27T14:57:18
|
|
Run the entire Cocoa messagebox function on the main thread.
This fixes bug https://github.com/libsdl-org/SDL/issues/4420
|
|
dfd3f30e
|
2021-07-27T14:27:37
|
|
Make Cocoa_HandleTitleButtonEvent() static since it's not used anywhere else
|
|
88e4755c
|
2021-07-27T12:43:00
|
|
Make sure we don't try to turn on relative mouse mode while clicking on the window title bar.
This fixes bug https://github.com/libsdl-org/SDL/issues/4469
|
|
f1633127
|
2021-07-24T13:41:55
|
|
Added a window flash operation to be explicit about window flash behavior
|
|
e1c3a250
|
2021-07-24T12:11:27
|
|
Changed SDL_FlashWindow() so it doesn't take a flash count, and added the hint SDL_HINT_WINDOW_FLASH_COUNT to control behavior on Windows
|
|
56b77b12
|
2021-06-04T19:51:58
|
|
cocoa: Implement FlashWindow
|
|
2f248a2a
|
2021-06-11T04:00:32
|
|
SDL_cocoaevents.m: fix build against SDK < 10.12 after commit 0dd7024d.
|
|
0dd7024d
|
2021-03-12T21:58:20
|
|
Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling
When possible use native os functions to make a blocking call waiting for
an incoming event. Previous behavior was to continuously poll the event
queue with a small delay between each poll.
The blocking call uses a new optional video driver event,
WaitEventTimeout, if available. It is called only if an window
already shown is available. If present the window is designated
using the variable wakeup_window to receive a wakeup event if
needed.
The WaitEventTimeout function accept a timeout parameter. If
positive the call will wait for an event or return if the timeout
expired without any event. If the timeout is zero it will
implement a polling behavior. If the timeout is negative the
function will block indefinetely waiting for an event.
To let the main thread sees events sent form a different thread
a "wake-up" signal is sent to the main thread if the main thread
is in a blocking state. The wake-up event is sent to the designated
wakeup_window if present.
The wake-up event is sent only if the PushEvent call is coming
from a different thread. Before sending the wake-up event
the ID of the thread making the blocking call is saved using the
variable blocking_thread_id and it is compared to the current
thread's id to decide if the wake-up event should be sent.
Two new optional video device methods are introduced:
WaitEventTimeout
SendWakeupEvent
in addition the mutex
wakeup_lock
which is defined and initialized but only for the drivers supporting the
methods above.
If the methods are not present the system behaves as previously
performing a periodic polling of the events queue.
The blocking call is disabled if a joystick or sensor is detected
and falls back to previous behavior.
|
|
9dc97afa
|
2021-05-08T12:39:50
|
|
cocoa: Report an error if SDL_SetClipboardText() isn't using UTF-8 encoding.
Fixes #4110.
|
|
8527c583
|
2021-04-27T01:36:23
|
|
cocoa: Fix recreated windows that are both borderless and resizable.
These would accidentally get a titlebar because the "borderless" style mask
is zero but the resizable attribute adds a bit. I assume this happens because
you used to need window decoration to resize a window in macOS, but this
changed in later releases.
This only caused problems when recreating a window (you had an
SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc).
Fixes #4324.
|
|
2fdbae22
|
2021-04-26T18:43:28
|
|
cocoa: Remove mouse event tap.
It doesn't appear to work anymore, and was disabled by default anyhow, since
the needed APIs are forbidden on the Mac App Store.
A better solution to lock the mouse to the window on macOS would still be
welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative
mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands
now, a grabbed mouse can briefly break out of the window, causing varying
degrees of chaos.
|
|
a0a5da5d
|
2021-04-19T07:13:38
|
|
Add SDL_SetWindowAlwaysOnTop()
|
|
9ef0b97c
|
2021-04-12T11:25:44
|
|
Changes to macOS event handler to better interact with the running app
- Only focus a new window when one closes if the window that was closed was an SDL window
- If the application already has a key window set that is not an SDL window, don't replace it when the application is activated
- Only register the URL event handler when SDLAppDelegate is going to be set as the applications app delegate. This is to
be consistent with previous behavior that would only register the handler in -[SDLAppDelegate applicationDidFinishLaunching:]
and allows the running app to opt out of the behavior by setting its own app delegate.
- The URL event handler is now removed if it was set on SDLAppDelegate dealloc
|
|
033c0abb
|
2021-03-27T14:04:00
|
|
Use dispatch_async for -[NSOpenGLContext update]. Fixes #3680
|
|
0052339b
|
2021-02-20T19:53:44
|
|
Move handleURLEvent setEventHandler to init
|
|
cef198c9
|
2021-02-01T08:55:48
|
|
Fixed bug 5524 - Pass NSString to NSLog()
Hiroyuki Iwatsuki
If you pass the C string directly to NSLog(), it will be garbled with Japanese and probably other language strings, or no log will be output at all.
NSLog("Hello, World!"); // => "Hello, World!"
NSLog("こんにちは、世界!"); // => No output...
Therefore, you need to convert the string to an NSString before passing it to NSLog().
NSString *str = [NSString stringWithUTF8String:"こんにちは、世界!"];
NSLog(@"%@", str); // => "こんにちは、世界!"
Thank you.
|
|
6b057c67
|
2021-01-26T19:16:17
|
|
Expose separate keyboard and mouse grab support
This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(),
SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new
SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise
this functionality and makes a minor fix to X11 that I missed in
https://hg.libsdl.org/SDL/rev/02a2d609369b
To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to
SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards
compatibility with older code.
|
|
a0d3c6c6
|
2021-01-25T21:42:14
|
|
Rename SetWindowGrab() to SetWindowMouseGrab()
|
|
e778881a
|
2021-01-07T11:49:28
|
|
Fixed bug 5449 - SDL_DROPFILE update mouse location of drop in Cocoa
Dominik Reichardt
Exult (http://exult.info) has an editor app that uses GTK+2. Up to now we were using X's drag'n'drop to allow dropping of assets from the editor onto Exult.
There is now an experimental branch that makes use of SDL_DROPFILE. That works under X, dropping in Exult's SDL2 window puts the asset right at the spot you dropped at.
On macOS with native Exult and Quartz GTK+2 this doesn't work, the location of the drop is where the mouse was last tracked before you left the window (usually one of the edges, unless you tabbed out).
All we tried out pointed to the fact that the location update needs to be done by the dropfile event in SDL2, not by our own (which always only worked after the Exult window getting focus).
This patch adds this to SDL_cocoawindow.m and it works perfectly, passing the correct coordinates to our code (SDL_GetMouseState()).
|
|
9130f7c3
|
2021-01-02T10:25:38
|
|
Updated copyright for 2021
|
|
963c9495
|
2021-01-02T10:11:08
|
|
Fixed bug 5431 - SDL_Metal_GetDrawableSize is inaccurate for high dpi displays if a Metal view has not already been created
Caleb Cornett
For a window created with SDL_WINDOW_ALLOW_HIGHDPI, SDL_GL_GetDrawableSize will return the high-dpi drawable size even before any GL context creation happens. But SDL_Metal_GetDrawableSize will return the size of the window if the Metal view has not been created. This is confusing and inconsistent behavior.
An easy way to test this is to build testgl2 and testvulkan on macOS with the SDL_WINDOW_ALLOW_HIGHDPI flag enabled during window creation. The GL2 program will report a drawable size of 2x window width and 2x window height, while the Vulkan program will report the window size.
This patch addresses the issue by falling back to using the content view dimensions if no Metal view exists in the window. (The code for this was taken directly from Cocoa_GL_GetDrawableSize.) With this change, the testvulkan behavior matches that of testgl2.
Note that I haven't tested for this issue on UIKit. It's possible a similar change will need to be made there too.
|
|
90456670
|
2020-12-17T14:11:00
|
|
more "'for' loop initial declarations are only allowed in C99 mode" fixes
|
|
ee85a41a
|
2020-12-13T02:10:46
|
|
Fixed compile warning
|
|
5c212cb0
|
2020-12-10T12:24:24
|
|
remove a few stale NULL message/title checks after commit e2b729b1756a
top-level guarantees non-NULL message / title passed in messageboxdata
|
|
cb361896
|
2020-12-09T07:16:22
|
|
Fixed bug 5235 - All internal sources should include SDL_assert.h
Ryan C. Gordon
We should really stick this in SDL_internal.h or something so it's always available.
|
|
b79832ba
|
2020-10-08T21:11:09
|
|
cocoa: Cut and paste from HTML strikes again!
|
|
19aaa294
|
2020-10-09T04:00:00
|
|
Fix https://bugzilla.libsdl.org/show_bug.cgi?id=5306
(Also see: https://bugzilla.libsdl.org/show_bug.cgi?id=4822)
Building the current tree against 10.8 SDK, clang emits the following warning:
src/video/cocoa/SDL_cocoawindow.m:1846:27: warning: instance method '-isOperatingSystemAtLeastVersion:' not found (return type defaults to 'id') [-Wobjc-method-access]
![processInfo isOperatingSystemAtLeastVersion:version]) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/MacOSX10.8.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSProcessInfo.h:20:12: note: receiver is instance of class declared here
@interface NSProcessInfo : NSObject {
^
1 warning generated.
isOperatingSystemAtLeastVersion is an 10.10 thing.
|
|
69fbd60d
|
2020-10-09T04:00:00
|
|
Fix https://bugzilla.libsdl.org/show_bug.cgi?id=4877#c2
loadNibNamed:owner:topLevelObjects is available on 10.8 and newer.
There is an issue report here about an app failing to function on
10.7 and earlier: https://discourse.libsdl.org/t/28179
|
|
76980e30
|
2020-10-08T16:42:20
|
|
Added events for dynamically connecting and disconnecting displays, with an iOS implementation
|
|
1b6de9a9
|
2020-09-05T15:01:45
|
|
Fix SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH=1 on Metal windows
SDL_cocoametalview was consuming the first click rather than passing it
through to the SDLView underneath which overrides [NSView acceptsFirstMouse]
based on the user's SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH preference.
|
|
b5affd12
|
2020-07-16T13:28:59
|
|
Patched to compile.
|
|
8babda2c
|
2020-07-16T13:18:19
|
|
egl: SDL_EGL_LoadLibaryOnly() shouldn't set _this->gl_config.driver_loaded = 1
This is handled in in the higher-level SDL_GL_LoadLibrary().
All uses of SDL_EGL_LoadLibrary (which calls the Only version) are just
target-specific wrappers for their own GL_LoadLibrary hook, with two
exceptions which now handle driver_loaded correctly (although it's
questionable if these init-if-no-one-did-it-correctly-already code blocks
should exist at all, fwiw).
Fixes Bugzilla #5190.
|
|
052a1373
|
2020-07-12T19:11:15
|
|
Merge VideoBootStrap::available into VideoBootStrap::create
The two are only ever called together, and combining them makes it possible
to eliminate redundant symbol loading and redundant attempts to connect
to a display server.
|
|
97ca96bd
|
2020-05-27T10:13:01
|
|
Use nil instead of NULL for Objective-C objects
|
|
af5eb56c
|
2020-05-27T09:28:03
|
|
Fixed uninitialized variable warning
|
|
77b0dad2
|
2020-05-25T20:55:29
|
|
cocoa: Change Caps Lock behavior to toggle instead of locking
It currently behaves like a locking key which is pressed
when Caps Lock is enabled and released when disabled. This
means that apps that trigger events on Caps Lock key down will
only fire these events every other time Caps Lock is pressed.
|
|
b47f577a
|
2020-05-11T14:36:23
|
|
Fixed bug 5098 - macOS CreateWindowFrom doesn't work with high-dpi displays
michaeljosephmaltese
Display ends up taking only 1/4 of the screen area. It needs to call "setWantsBestResolutionOpenGLSurface:highdpi", like when creating a window the normal way.
|
|
fa23e3d0
|
2020-05-04T02:27:29
|
|
locale: Implemented SDL_GetPreferredLocales().
This was something I proposed a long time ago, Sylvain Becker did
additional work on it, then back to me.
Fixes Bugzilla #2131.
|
|
a7916890
|
2020-04-10T00:37:35
|
|
metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!).
Caleb Cornett's comments:
"A few weeks ago, Alex added a partial Metal API to SDL2:
https://hg.libsdl.org/SDL/rev/22c8e7cd8d38
I noticed it was missing a few features that would help Metal become a
first-class citizen in SDL, so I went ahead and wrote them! Here are the new
APIs:
1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer
to specify that they intend to create a window for use with SDL_MetalView.
The flag is used to ensure correct usage of the API and to prevent
accidentally defaulting to OpenGL on iOS.
2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a
pointer to the view's backing CAMetalLayer. This simplifies things
considerably, since in the current version of the SDL_Metal API the
programmer is required to bridge-cast a SDL_MetalView handle to an NSView or
UIView (depending on the platform) and then extract the layer from there.
SDL_Metal_GetLayer automatically handles all of that, making the operation
simple and cross-platform.
3. SDL_Metal_GetDrawableSize(). This function already exists in the current
SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize
on Apple platforms) but was not publicly exposed. My patch exposes this
function for public use. It works just like you'd expect.
Tested on macOS 10.14 and iOS 12.4."
Fixes Bugzilla #4796.
|
|
6e6b5177
|
2020-04-07T23:34:41
|
|
cocoa: Patched to compile.
|
|
309d6137
|
2020-04-07T14:01:25
|
|
cocoa: OpenGL setView and update must be used on main thread (thanks, Tim!).
If called from background threads, use Grand Central Dispatch to use the
main thread instead. On the main thread, just call them directly.
Fixes Bugzilla #4932.
|
|
b6afbe63
|
2020-04-07T09:38:57
|
|
Added SDL_log.h to SDL_internal.h so logging is available everywhere
|
|
dad73b1f
|
2020-04-05T10:47:58
|
|
Fixed bug 5073 - SDL does not handle URL Schemes in MacOS
Jason
In iOS, URL Events trigger the DropFile event. I would also expect the same event to be fired on the macOS platform but this is not implemented at all in the AppDelegate.
|
|
f2ff953e
|
2020-03-26T13:42:56
|
|
cocoa: Just update the OpenGL context directly if on the main thread.
|
|
361417c0
|
2020-03-25T16:40:43
|
|
cocoa: allow calling CreateWindowFrom on an NSView
This lets applications embed SDL with other widgets surrounding it.
Already possible on Windows and X11.
Fixes Bugzilla #5060.
|
|
1fd548b6
|
2020-03-23T11:42:44
|
|
Fixed building back to Mac OSX using the 10.7 SDK
|
|
5b3b55a1
|
2020-03-20T11:52:18
|
|
[NSOpenGLContext update[ is prohibited outside the main thread
|
|
51e9e984
|
2020-03-01T13:00:50
|
|
Fixed whitespace
|
|
8a6f1aa5
|
2020-03-01T12:58:50
|
|
Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds.
Elmar
creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar.
Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14).
Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace:
const int maxattempts = 3;
int attempt = 0;
while (++attempt <= maxattempts) {
/* Wait for the transition to complete, so application changes
take effect properly (e.g. setting the window size, etc.)
*/
const int limit = 10000;
int count = 0;
while ([data->listener isInFullscreenSpaceTransition]) {
if ( ++count == limit ) {
/* Uh oh, transition isn't completing. Should we assert? */
break;
}
SDL_Delay(1);
SDL_PumpEvents();
}
if ([data->listener isInFullscreenSpace] == (state ? YES : NO))
break;
/* Try again, the last attempt was interrupted by user gestures */
if (![data->listener setFullscreenSpace:(state ? YES : NO)])
break; /* ??? */
}
One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user.
Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs.
Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself.
Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around.
Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first.
I can unfortunately not provide a minimum example.
Best regards,
Elmar
0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207
1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401
2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370
3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512
4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692
5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349
6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135
7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36
8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82
9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8
10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322
11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807
12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335
14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463
15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293
16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371
17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64
18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997
19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290
21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23
22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223
23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555
24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118
25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135
26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188
27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546
28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573
29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347
30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614
31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460
32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383
33 com.yasara.View 0x0000000100418e39 mod_main + 815
34 com.yasara.View 0x000000010029ca5d main2 + 5766
35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19
|
|
094655cf
|
2020-02-23T14:49:03
|
|
cocoa: Make sure wait for button enable can't be infinite.
|
|
72316518
|
2020-02-23T14:48:48
|
|
cocoa: Removed a debug printf that was accidentally committed.
|
|
4d9e6e5f
|
2020-02-21T14:50:09
|
|
cocoa: When exiting a fullscreen space, wait for window state to normalize.
A good metric of this is when the titlebar's "minimize" button is reenabled,
which doesn't happen by the time windowDidExitFullscreen triggers.
This fixes minimizing a fullscreen window on macOS.
Fixes Bugzilla #4177.
|
|
0a6d80ab
|
2020-02-12T13:08:29
|
|
mac: Wait a bit before activating app at startup.
This is obnoxious and wrong, but the patch that activates the Dock before
activating the app fixes the _menu_ not responding on Catalina, but the
first window created by the app won't have keyboard focus without a small
delay inserted.
This obviously needs a better solution, but it gets it limping along correctly
for now.
|
|
fe8ce66b
|
2020-02-11T10:35:14
|
|
Attempt to make version detection safe for Mac OS X < 10.10
|
|
52b410ab
|
2020-02-11T10:21:31
|
|
Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15
sjordan
We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors.
We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case.
We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time.
We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not.
We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case.
I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that.
...
Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen:
/* Hack to fix origin on Mac OS X 10.4 */
NSRect screenRect = [[nswindow screen] frame];
if (screenRect.size.height >= 1.0f) {
rect.origin.y += (screenRect.size.height - rect.size.height);
}
If we comment this one out our game and testdraw2 do behave correctly.
It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later).
We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions).
More info: consider the line
NSRect screenRect = [[nswindow screen] frame];
in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop
on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise.
On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window.
What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result?
Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.
|
|
c9c89783
|
2020-01-29T20:09:08
|
|
Miscellaneous pending fixes
|
|
c7e1b289
|
2020-01-27T17:15:12
|
|
cocoa: Fix command line apps' menu bar not working on macOS Catalina.
Fixes Bugzilla #4937.
|