Closed zellyn closed 2 weeks ago
Confirmed on M1 Air, macOS 13.2.1 Pixelorama v0.10.3
Looks to be caused by this (54519), if I disable multithreading it can be resized fine.
I can confirm this also on M1 pro
Process: Pixelorama [80759] Path: /Applications/Pixelorama.app/Contents/MacOS/Pixelorama Identifier: com.orama-interactive.pixelorama Version: 0.10.3 (0.10.3) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501
Date/Time: 2023-04-15 01:44:21.1777 -0700 OS Version: macOS 13.3.1 (22E261) Report Version: 12 Anonymous UUID: 146874A7-4833-7151-D6B9-118E053B09DA
Confirmed on M1 Air, macOS 13.2.1 Pixelorama v0.10.3
Looks to be caused by this (54519), if I disable multithreading it can be resized fine.
Are you certain that this is the cause? It looks like that issue has been solved since November 2021, before Godot 3.5 was released. Pixelorama v0.10.3 is using Godot 3.5, so that issue should, in theory, not occur. Unfortunately, I do not own a Mac device to test it.
Not certain it is 54519, but it seems likely (I did see the issue was resolved and wasn't sure if it was a regression or perhaps still possible to trigger).
To test I downloaded Godot 3.5.2 and cloned the current Pixelorama master branch.
100% of the time I could reproduce crashing on resizing with click and drag corners (resizing with keyboard shortcuts does not seem to crash).
After setting Project Settings > Rendering > Threads > Thread Model > [Single-UnSafe, Single-Safe, Multi-Threaded] on both Single-Unsafe and Single-Safe it never crashed.
I'm somewhat of a Godot noob, but happy to test anything on an M1 and let you know the result. When it crashes there are no errors in the Godot editor, it is just caught by Mac's crash reporting system (which creates @zellyn's original post).
Hmm, it could be a Godot regression then. Can you test if the issue occurs with the GLES3 renderer? The next version of Pixelorama (current master branch) will let users change the renderer from the preferences, so if the crash doesn't happen with GLES3, it could be a nice workaround. Alternatively we could use single-threaded mode, but I'm not sure if it would work with gif exporting, which uses multi-threading.
Same result regardless of GLES2/GLES3 (ie. 100% crashes on multi threaded, never crashes on single)
Hi, same for me with Mac M1 Ultra. Ventura 13.3.1
As @kalenpw said " After setting Project Settings > Rendering > Threads > Thread Model > [Single-UnSafe, Single-Safe, Multi-Threaded] on both Single-Unsafe and Single-Safe"
👉 it never crashed.
You can run the app using --render-thread safe
(this is a Godot CLI argument). This allows you to override the thread model without having to import the project in the Godot editor and run it from there.
Alternatively we could use single-threaded mode, but I'm not sure if it would work with gif exporting, which uses multi-threading.
I'm surprised the GIF exporter would need that. This project setting only affects how rendering is performed with regards to CPU work, not whether you can use the Thread class in the project.
We can use apple script to create an app.
Then use following script, and save as app:
do shell script "open -a '/Applications/Pixelorama.app/Contents/MacOS/Pixelorama' --args --render-thread safe"
It seems work perfect.
Does this still occur with version 1.0?
Does this still occur with version 1.0?
FWIW I am no longer encountering this issue with 1.0.
Pixelorama version: 0.10.3. Tried both .dmg and homebrew versions.
OS/device including version: Apple M1 Max
Issue description: Resized window by dragging a corner. App crashed.
Steps to reproduce: Open Pixelorama. Try to drag a corner of the window. If you drag very quickly and release your mouse button immediately, it's fine. If you keep dragging, it crashes reliably.
"Report to Apple" details