Added Surface::{width,height} implementations for CGL/WGL

[Melchizedek6809]

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

Hello again,

I've looked into implementing these missing methods on CGL/WGL. For the CGL implementation I'm not sure whether the nil check is necessary, if not then the maybe the return type could be changed to u32 since all Platforms have an implementation now?

[madsmtm]

Ideally, the != nil check in CGL should be moved to create_window_surface. Perhaps one could even change the type from ns_view: id to ns_view: NonNull<Object>.

[Melchizedek6809]

@madsmtm Alright, I've moved the check into create_window_surface. Changing the type to ns_view: NonNull<Object> seems like a bigger change, I might tackle that in a separate PR.

Apart from that this newest change means that Surface::{width,height} will always return Some on all APIs, would changing the return type from Option<u32> to u32 be appropriate?

[kchibisov]

@MarijnS95 could you look into the android failure? It looks like the ndk just doesn't build, given that traces don't go into glutin?

[MarijnS95]

@kchibisov this was caused by num_enum 0.5.8 which has aptly been yanked. I've restarted the CI, should become green soon again.

[kchibisov]

@madsmtm could you take a look, I think I've fixed all thread safety issues with macOS and were able to run stuff off the main thread, though, I've removed the example due to its complexity...

I've also clarified the docs and ensured that we return physical sizes from the width/height` functions.

[kchibisov]

Also, @madsmtm do you know a way to somehow wakeup macOS's main thread from set_wait in winit? Without side channels and such, maybe there's a global method to magically wake-it-up?

[madsmtm]

@madsmtm could you take a look

Looks good to me now 👍

Also, @madsmtm do you know a way to somehow wakeup macOS's main thread from set_wait in winit? Without side channels and such, maybe there's a global method to magically wake-it-up?

I assume you mean after having called ControlFlow::set_wait? But yes, what we do in winit to do so is to send an empty NSEvent:

https://github.com/rust-windowing/winit/blob/5ba6bdef4931e66eb4c4be87c90a51fad7675ee5/src/platform_impl/macos/event_loop.rs#L260

[kchibisov]

I assume you mean after having called ControlFlow::set_wait? But yes, what we do in winit to do so is to send an empty NSEvent:

I wonder if I can do so from inside glutin, I think I can do so, given that NSApplication is a singleton? Might be worth force waking-up the event loop like that?

[madsmtm]

You definitely could - though I don't think I understand why you need to?

[kchibisov]

If winit is blocked on the main thread, and you call something on the off thread, you'll block on the off-thread as well. If we send dummy event we'll wake-up the main loop without any issue?

Otherwise the user must wake-up the main thread manually when calling functions in glutin which block on macOS?

[madsmtm]

No, you needn't worry about that: Queue::main().exec_sync(|| ...) wakes up the main event loop for you

[kchibisov]

Huh, ok.