Cocoa Metal example (no SDL). #52

yay · 2024-08-20T23:00:18Z

Have you added the example to the CI at .github/workflows/check.yml?

yay · 2024-08-20T23:11:04Z

PR to fix build from failing (vet tabs): odin-lang/Odin#4117

laytan · 2024-08-26T16:19:22Z

ols.json

Can you remove this file? You may also add it to .gitignore

Ah, didn't mean to commit it.

mbger · 2024-08-26T20:40:05Z

Just took the sample for a spin and here are a few observations. Hope you don't mind me chiming in.

The other samples all have a way of exiting the main loop (e.g. pressing escape to set a quit flag to true). This is missing here. Therefor the compiler does not complain that there's no return statement at the end of metal_main. When I implemented this 'press escape to quit' functionality the program would segfault when exiting metal_main. I think this happens because metal_main sets up a scoped autorelease pool? I.e. when exiting metal_main already-released objects get released again wich causes the segfault.

Also, the program currently fetches just one event per main-loop iteration instead of draining all events from the queue. But this might be intentional?

Those were essentially my modifications:

// `metal_main`
{
    // Setup... (but remove call to NS.scoped_autoreleasepool() to prevent segfault)

    // Main Loop
    for quit := false; !quit;
    {
	// Poll all events from the queue
	for
	{
	    e := app->nextEventMatchingMask(NS.EventMaskAny, nil, NS.DefaultRunLoopMode, true)
	    
	    if e == nil { break }
	    
	    #partial switch e->type()
	    {
		case .KeyDown, .KeyUp:
		code := NS.kVK(e->keyCode())
		#partial switch code {
		    case .Escape:
		    quit = true
		    case .LeftArrow:
		    angle -= 0.02
		    case .RightArrow:
		    angle += 0.02
		    case:
		    fmt.println(code)
		}
		
		case:
		fmt.println(e->locationInWindow(), e->modifierFlags())
		app->sendEvent(e)
	    }
	}

	// Render frame...
    }

    // Exit `metal_main`
    return nil
}

yay · 2024-08-26T22:59:08Z

@mbger Thanks! I added the Escape key handling. The reason I used NS.Date.distantFuture() is to keep CPU usage at 0% on idle. If I poll all events and use nil instead, idle CPU usage is quite high.

I wonder if there's a memory leak somewhere? If I press left or right key and hold it for a minute, memory usage for the process will slowly keep increasing. With or without the NS.scoped_autoreleasepool() statement.

mbger · 2024-08-27T07:50:18Z

I wonder if there's a memory leak somewhere? If I press left or right key and hold it for a minute, memory usage for the process will slowly keep increasing. With or without the NS.scoped_autoreleasepool() statement.

In your original example, the scoped autorelease pool never has a chance to release anything because the relevant scope never exits. I think what might help is to set up a scoped autorelease pool specifically for the event-polling section of our code (though I can't test now):

    // Main Loop
    for quit := false; !quit;
    {
	// Poll all events from the queue
	{   
	    NS.scoped_autoreleasepool()
	    
	    for
	    {
		e := app->nextEventMatchingMask(NS.EventMaskAny, nil, NS.DefaultRunLoopMode, true)
		
		if e == nil { break }
		
		#partial switch e->type()
		{
		    case .KeyDown, .KeyUp:
		    code := NS.kVK(e->keyCode())
		    #partial switch code {
			case .Escape:
			quit = true
			case .LeftArrow:
			angle -= 0.02
			case .RightArrow:
			angle += 0.02
			case:
			fmt.println(code)
		    }
		    
		    case:
		    fmt.println(e->locationInWindow(), e->modifierFlags())
		}
		app->sendEvent(e)
	    }
	}

	// Render frame

yay · 2024-08-27T10:56:54Z

I think what might help is to set up a scoped autorelease pool specifically for the event-polling section of our code

Yes, that's definitely an improvement. Just made that change. It still looks like it might be leaking a little though.

laytan · 2024-08-27T17:19:43Z

One thing I've noticed is that pressing the x to close the app just closes the window but doesn't quit the program.

yay · 2024-08-27T17:26:05Z

Yes, one needs to create an AppDelegate and implement one of its methods to handle x button behavior. But IDK how to combine that and explicit event loop handling.

laytan · 2024-08-27T22:06:52Z

Yes, one needs to create an AppDelegate and implement one of its methods to handle x button behavior. But IDK how to combine that and explicit event loop handling.

That seems like a blocker to me, any application should support properly closing like that

yay · 2024-08-27T22:53:31Z

No problem. Should I keep this open or close and reopen when I have an idea how to do that?

I don't have any immediate plans to explore further, the AppDelegate stuff is way over my head and I'm making more progress elsewhere.

laytan · 2024-08-27T23:01:48Z

You don't have to close it, maybe somebody else sees it and is able to implement the missing things.

colrdavidson · 2024-08-28T04:05:26Z

I don't know how useful it is, but I did something like this a while back
https://gist.github.com/colrdavidson/aecf689196fcae49122749f866780854#file-osx_platform-odin-L190

mbger · 2024-08-28T07:50:58Z

I don't have any immediate plans to explore further, the AppDelegate stuff is way over my head and I'm making more progress elsewhere.

I think you're in good company. This stuff is tricky to get right and after doing a bit of research I think every approach will have its drawbacks. See for example this discussion in the sokol project. (AFAICT they don't set up their own main loop but start the NSApp run loop and hook int the main window's drawRect: to render each frame)

As for the immediate PR-blocking issue here (exiting the program when the window is closed): I think we could register a NSWindowDelegate and set our quit flag in windowWillClose: like this:

Make the quit flag global and add the windowWillClose: procedure

// Global scope
quit := false

windowWillClose :: proc (^NS.Notification)
{
    quit = true
}

Register the NSWindowDelegate in our setup code:

    //  metal_main
    window->setDelegate(NS.window_delegate_register_and_alloc({
	windowWillClose = windowWillClose
    }, "MainWindowDelegate", context))

yay · 2024-08-28T09:42:40Z

@mbger Thank you! Just pushed those changes. Now there are 4 different ways to close the app. From the menu, via Cmd+Q shortcut, by pressing Escape, and by clicking the x button.

@colrdavidson Thanks! But I don't see where the get_next_event proc is being called?

yay · 2024-08-28T09:53:54Z

On a separate note, when pressing keyboard keys, the app makes those beep sounds, as if the action is invalid.

If I don't call app->sendEvent(event) on case .KeyDown, .KeyUp, no beep sounds are made, but then if I press Cmd+Q the app also doesn't exit.

I guess I can handle Cmd+Q separately, there is enough information for me do that, but I wonder if there's a better way to suppress those beep sounds? EDIT: actually, that wouldn't really work, because that would require special handling for all shortcuts, not just Cmd+Q.

mbger · 2024-08-28T14:50:22Z

Don't know if that's the way to do it, but what worked for me is to create a custom subclass of NSWindow which overrides keyDown:. Not sure if that approach breaks some other stuff down the road though... (I don't have a ton of experience with macOS dev)

USE_CUSTOM_WINDOW :: true

    // ...

    window: ^NS.Window

    when USE_CUSTOM_WINDOW
    {	
	customWindowClass := NS.objc_allocateClassPair(intrinsics.objc_find_class("NSWindow"), strings.clone_to_cstring("CustomWindow", context.temp_allocator), 0)

	keyDown :: proc "c" (event: ^NS.Event) { /* ignore key down events */ }

	assert(customWindowClass != nil)
	
	NS.class_addMethod(customWindowClass, intrinsics.objc_find_selector("keyDown:"), auto_cast keyDown, "v@:@")
	NS.objc_registerClassPair(customWindowClass)
	keyIgnoringWindow := NS.class_createInstance(customWindowClass, size_of(NS.Window))
	window = cast(^NS.Window)keyIgnoringWindow
    }
    else
    {
	window = NS.Window.alloc()
    }

    defer window->release()

yay · 2024-08-31T17:25:41Z

Apparently, one can override the acceptsFirstResponder property to return true: https://stackoverflow.com/questions/13519647/silence-cocoa-error-beep

But I haven't figured out how to do that yet. Is that the same as overriding a method?

There are these ObjC Runtime functions:

class_addProperty           :: proc(cls: Class, name: cstring, attributes: [^]objc_property_attribute_t, attributeCount: uint) -> BOOL ---
class_replaceProperty       :: proc(cls: Class, name: cstring, attributes: [^]objc_property_attribute_t, attributeCount: uint) ---

But I'm reading that you can't actually add properties at runtime: https://stackoverflow.com/questions/7819092/how-can-i-add-properties-to-an-object-at-runtime

So I'm confused. This doesn't make it stop beeping on key press:

CustomWindowClass := NS.objc_allocateClassPair(intrinsics.objc_find_class("NSWindow"), strings.clone_to_cstring("CustomWindow", context.temp_allocator), 0)
assert(CustomWindowClass != nil)
assert(NS.class_getProperty(CustomWindowClass, "acceptsFirstResponder") != nil)
acceptsFirstResponder :: proc "c" () -> NS.BOOL { return NS.YES }
sel := intrinsics.objc_find_selector("acceptsFirstResponder")
assert(NS.class_respondsToSelector(CustomWindowClass, sel) == true)
NS.class_addMethod(CustomWindowClass, sel, auto_cast acceptsFirstResponder, "B@:")
NS.objc_registerClassPair(CustomWindowClass)
window := cast(^NS.Window)(NS.class_createInstance(CustomWindowClass, size_of(NS.Window)))
defer window->release()

In the meantime, I've submitted this as I keep researching: odin-lang/Odin#4171

mbger · 2024-09-02T07:54:35Z

Apparently, one can override the acceptsFirstResponder property to return true: https://stackoverflow.com/questions/13519647/silence-cocoa-error-beep

[...]
So I'm confused. This doesn't make it stop beeping on key press:

Maybe the accepted answer is just incorrect and there's nothing wrong with how your Odin code? Have you tried to confirm the accepted answer with Xcode > File > New Project?

yay · 2024-09-02T21:34:36Z

Maybe the accepted answer is just incorrect and there's nothing wrong with how your Odin code? Have you tried to confirm the accepted answer with Xcode > File > New Project?

Well, acceptsFirstResponder indeed doesn't work in both Objective-C and Odin.
But performKeyEquivalent does! And key presses are silent.

performKeyEquivalent :: proc "c" (event: ^NS.Event) -> NS.BOOL { return NS.YES }
NS.class_addMethod(CustomWindowClass, intrinsics.objc_find_selector("performKeyEquivalent:"), auto_cast performKeyEquivalent, "B@:@")

However, Cmd+Q stops working.

mbger · 2024-09-03T07:23:30Z

Just curious: What are the downsides with the approach I outlined in a previous comment? At least on my end everything seems to work just fine – no beeps and CMD+Q quits the program.

yay · 2024-09-03T10:15:49Z

I would prefer not to ignore the key down event, if possible. My intent was to show how to create a macOS GUI that idles with zero CPU usage in the absence of events. And when typing, characters show up on screen on key down event. Though it's probably equally as important for games.

Of course, I can just use your solution (which I'm grateful for btw) just to get this PR to merge. But I wonder if there's something else we can try? This has been a very productive conversation so far.

laytan · 2024-09-04T13:24:36Z

Yep, your gist also doesn't work:

focus.mov

mbger · 2024-09-04T14:14:57Z

Thanks! Are you running your browser & terminal/editor in some special windowing mode? Looks a bit like the macOS native fullscreen split mode but w/o the divider in the middle. For me it looks like this:

CleanShot.2024-09-04.at.16.13.12.mp4

laytan · 2024-09-04T14:27:51Z

Thanks! Are you running your browser & terminal/editor in some special windowing mode? Looks a bit like the macOS native fullscreen split mode but w/o the divider in the middle. For me it looks like this:

Nothing special going on afaict, I do have Yabai but disabling that doesn't help, my terminal is Alacritty.
It all works as expected with the SDL version and any other app I have tried.

I think we should just put in the deprecated app->activateIgnoringOtherApps(true) since that is what GLFW and Sokol do (I haven't looked at what SDL does).

mbger · 2024-09-04T14:49:37Z

I think we should just put in the deprecated app->activateIgnoringOtherApps(true) since that is what GLFW and Sokol do (I haven't looked at what SDL does).

Well... I guess this explains why in your case the app is also half hidden behind alacritty at first and then ordered in front... 😄

See: https://github.com/libsdl-org/SDL/blob/f317581c91961ee628446886dd4df87e9c16ac79/src/video/cocoa/SDL_cocoaevents.m#L328

yay · 2024-09-04T18:07:30Z

Weird,

window->makeKeyAndOrderFront(nil)
app->finishLaunching()

is what I tried and it didn't work for me.

But activate did the trick.

I'm on macOS 15.0 Beta (24A5331b), if that matters.

yay · 2024-09-04T22:12:13Z

@laytan I replaced app->activate() with app->activateIgnoringOtherApps(true).

yay · 2024-09-04T22:41:46Z

Hmm...

So what do we do to merge this PR?

laytan · 2024-09-04T23:08:51Z

odin-lang/Odin@ddf5ca7 👿

yay · 2024-09-04T23:29:20Z

odin-lang/Odin@ddf5ca7 👿

Cool. I think we're good to go now.

yay · 2024-09-05T18:44:48Z

This is amazing actually. This has been annoying me for years! On any platform.

In macOS Sonoma, we have introduced Cooperative App Activation. Cooperative app activation reduces unexpected application switches, for example, an app switch while you are in the middle of typing.

There are two parts to cooperative app activation. Activate is now a request, as opposed to a command. The system considers the broader context of what the user is doing to decide if the activate request is appropriate. The new yield API allows an application to influence the context of a future activation request.

Now that activate is a request, the ignoringOtherApps parameter and option are ignored. As such, in macOS Sonoma, the activate(ignoringOtherApps:) function and the activateIgnoringOtherApps option are both deprecated. Replace them with the new activate APIs for NSApplication and NSRunningApplication.

More here: https://developer.apple.com/videos/play/wwdc2023/10054/

So I think we should change back to app->activate().

laytan · 2024-09-05T18:53:11Z

Well as we have seen here, it clearly doesn't work well enough yet. I am guessing apps that open others have to implement something (that yield concept) and until they do just an ->activate doesn't work.

yay · 2024-09-05T19:06:51Z

Not sure how activateIgnoringOtherApps would work though, if Now that activate is a request, the ignoringOtherApps parameter and option are ignored.

Either way, I'm happy for this to be merged as is too.

laytan · 2024-09-05T19:21:29Z

Now that activate is a request, the ignoringOtherApps parameter and option are ignored.

It looks like this is not yet the case. I think it's good to leave like this so it behaves like glfw, SDL, and Sokol does, we can always revisit later.

I will look over the entire pr once more in a bit and merge if there is nothing else, great work here any way!

laytan · 2024-09-05T22:19:18Z

Ah man it is not quite there yet, sorry :(

If you minimise the app you can't get it back into focus by clicking it in the dock.

You also can't quit the app by right clicking the dock entry and clicking on quit.

mbger · 2024-09-06T11:44:52Z

Ah man it is not quite there yet, sorry :(

If you minimise the app you can't get it back into focus by clicking it in the dock.

You also can't quit the app by right clicking the dock entry and clicking on quit.

Weird that we're experiencing such different behavior.

If I minimize it's still active and receives events. And right-click -> quit from the dock icon quits the program.

laytan · 2024-09-06T12:37:02Z

Weird that we're experiencing such different behavior.

Oh that is weird, I assumed this would reproduce for you too. I did confirm that the sdl version worked as expected, but let me investigate some more.

yay · 2024-09-06T18:10:48Z

If I minimize it's still active and receives events.

Same here. And I can restore it by clicking the dock icon.

You also can't quit the app by right clicking the dock entry and clicking on quit.

But also same here. Selecting "Quit" from dock icon's context menu does nothing.

Weird that we're experiencing such different behavior.

Indeed.

yay · 2024-09-11T15:59:18Z

I managed to find an example in pure C:
https://github.com/EimaMei/Silicon/blob/main/examples/general/events.c
Build with: gcc -g -o0 -Wall examples/general/events.c -I./ -framework Cocoa -o events

(funny enough, it's bases on the Obj-C example I was already using)

But after literal translation to Odin, the Odin app simply doesn't quit from the dock icon menu, whereas the C app does.

Here's my Odin code:

package main

import NS "core:sys/darwin/Foundation"

main :: proc() {
	app := NS.Application.sharedApplication()

	window1 := NS.Window.alloc()->initWithContentRect({{100, 100}, {300, 300}}, { .Titled, .Closable, .Miniaturizable, .Resizable }, .Buffered, false)
	window1->setIsVisible(true)

	app->setActivationPolicy(.Regular)
	app->finishLaunching()

	for {
		NS.scoped_autoreleasepool()
		event := app->nextEventMatchingMask(NS.EventMaskAny, NS.Date.distantFuture(), NS.DefaultRunLoopMode, true)

		if event->type() == .KeyDown && NS.kVK(event->keyCode()) == .ANSI_Q { break }

		app->sendEvent(event)
		app->updateWindows()
	}
}

laytan · 2024-09-11T21:33:05Z

That small example and comparison allowed me to debug it and I found the issue, working on a fix.

yay · 2024-09-11T21:43:47Z

Is it something to do with objc_msgSend? Or Application not extending NSResponder? I've been trying to figure it out all evening.

laytan · 2024-09-11T22:12:55Z

It was because our EventMaskAny was wrong, now fixed through odin-lang/Odin@27ed107 and odin-lang/Odin@201a7b9

laytan · 2024-09-11T22:35:10Z

I believe the last thing you need here is a call to app->finishLaunching()

yay · 2024-09-12T00:39:48Z

Ah, so the right events were not coming through.

I believe the last thing you need here is a call to app->finishLaunching()

Done, thanks. Indeed, the dock menu Quit didn't work without this one even with the new mask.

laytan · 2024-09-12T11:30:59Z

Thanks for sticking with me and all the work here, this is a very nice example to accompany the native win32 example!

mbger · 2024-09-13T15:44:05Z

Nice, thank you!

yay force-pushed the cocoa-metal branch from e8c0a88 to 4dd371f Compare August 21, 2024 11:48

laytan reviewed Aug 26, 2024

View reviewed changes

yay force-pushed the cocoa-metal branch from 4dd371f to e43db6c Compare August 26, 2024 23:00

yay force-pushed the cocoa-metal branch from e43db6c to adf48a6 Compare August 27, 2024 10:55

yay force-pushed the cocoa-metal branch from adf48a6 to e173f20 Compare August 27, 2024 20:11

yay force-pushed the cocoa-metal branch from e173f20 to 9c5e073 Compare August 28, 2024 09:37

yay force-pushed the cocoa-metal branch from 9c5e073 to 1c2cbf0 Compare August 28, 2024 09:48

yay force-pushed the cocoa-metal branch 3 times, most recently from 3e74173 to 2b21d06 Compare September 3, 2024 13:21

Bring app to foreground on launch.

f0f4c8f

yay force-pushed the cocoa-metal branch from 933e1a1 to f0f4c8f Compare September 4, 2024 22:11

Fix keyDown method signature and remove auto_cast.

dc82dd6

Add app->finishLaunching() call.

eeed082

laytan merged commit b88eef8 into odin-lang:master Sep 12, 2024
1 check passed

Cocoa Metal example (no SDL). #52

Cocoa Metal example (no SDL). #52

Conversation

yay commented Aug 20, 2024 • edited Loading

yay commented Aug 20, 2024

laytan Aug 26, 2024

Choose a reason for hiding this comment

yay Aug 26, 2024

Choose a reason for hiding this comment

mbger commented Aug 26, 2024

yay commented Aug 26, 2024 • edited Loading

mbger commented Aug 27, 2024

yay commented Aug 27, 2024

laytan commented Aug 27, 2024

yay commented Aug 27, 2024

laytan commented Aug 27, 2024

yay commented Aug 27, 2024

laytan commented Aug 27, 2024

colrdavidson commented Aug 28, 2024

mbger commented Aug 28, 2024 • edited Loading

yay commented Aug 28, 2024

yay commented Aug 28, 2024 • edited Loading

mbger commented Aug 28, 2024

yay commented Aug 31, 2024 • edited Loading

mbger commented Sep 2, 2024

yay commented Sep 2, 2024

mbger commented Sep 3, 2024

yay commented Sep 3, 2024

laytan commented Sep 4, 2024

mbger commented Sep 4, 2024

laytan commented Sep 4, 2024

mbger commented Sep 4, 2024

yay commented Sep 4, 2024

yay commented Sep 4, 2024

yay commented Sep 4, 2024

laytan commented Sep 4, 2024

yay commented Sep 4, 2024

yay commented Sep 5, 2024

laytan commented Sep 5, 2024

yay commented Sep 5, 2024

laytan commented Sep 5, 2024

laytan commented Sep 5, 2024

mbger commented Sep 6, 2024

laytan commented Sep 6, 2024

yay commented Sep 6, 2024 • edited Loading

yay commented Sep 11, 2024 • edited Loading

laytan commented Sep 11, 2024

yay commented Sep 11, 2024

laytan commented Sep 11, 2024

laytan commented Sep 11, 2024

yay commented Sep 12, 2024

laytan commented Sep 12, 2024

mbger commented Sep 13, 2024

yay commented Aug 20, 2024 •

edited

Loading

yay commented Aug 26, 2024 •

edited

Loading

mbger commented Aug 28, 2024 •

edited

Loading

yay commented Aug 28, 2024 •

edited

Loading

yay commented Aug 31, 2024 •

edited

Loading

yay commented Sep 6, 2024 •

edited

Loading

yay commented Sep 11, 2024 •

edited

Loading