Welcome to tomaka/glutin, the official gitter channel for Glutin and Winit! - Github: https://github.com/rust-windowing/glutin, https://github.com/rust-windowing/winit - Crates.io: https://crates.io/crates/glutin, https://crates.io/crates/winit - Docs: https://docs.rs/glutin/0.21.0/glutin, https://docs.rs/winit/0.20.0/winit/
i am in a deadlock now 😿 can't test if transparency is working with winit without rendering anything. can't test if transparency is working with rendering by wgpu-rs because it doesn't support transparency yet
maroider: RE: opening a window from node js and not blocking node's event loop: You were completely right the whole time. There is no other way than exiting the Winit / NSApp event loop and picking up from there*. I have looked at other implementations, esp. GLFW and they too just start the loop, wait for the "applicationDidFinishLaunching" event and stop the loop.
there might be another way by moving node's event loop into a thread, but that is a whole different story
maroider: I don't know if I annoy you or if you're interested, but i think I got an idea of this non-breaking event-loop thing now, at least for macOS. You probably already know that Cocoa wants you to use NSApp run, which is blocking and kind of wants to to just accept their main loop and that's it. There are a couple of libraries that tried to circumvent that API design and some blogpost that basically found hacks or undocumented ways to get out of this restraint. Usually you would call stop on the app in your app delegate's applicationDidFinishLoading event. This mean you stop the event loop, however your window stays on the screen, it just does not respond to events anymore. Luckily you can pick up from there and imlement your own event loop by polling nextEventMatchingMask in your loop. Another way is to subclass NSApp and override the run method and use nextEventMatchingMask there.
It's all crazy hacky and probably not something you wanna bet a lot of money on, but there are a few bigger libraries out there that just go with that
I am not sure on the CPU usage though when you poll nextEventMatchingMask like a looney