GeezerVison

Implements the basic rendering lifecycle needed to drive bevy forward from the processing event loop.

When a PSurfaceGLFW is created, we pass the window handle over ffi and import it into bevy. Bevy then will create the underlying wgpu surface via its ordinary operations for windows. The Window here we insert is a non-functional facade -- we'll make sure to synchronize it from the Java side but have no need atm to allow bi-directional communication (i.e. bevy resizes Glfw).

There's some additional work we'll need to do to think about multi-window support. Right now we're driving the wgpu renderer forward in endDraw on PGraphicsWebGPU but this may not be correct in the presence of multiple graphics contexts.

Basically, for implementing the main processing api, what we'll want to do is run all the user's functions to build up a frame's worth of abstract draw data on the Rust side (i.e. insert stuff into the ECS world as needed) and then run update once at the end of frame which will drive the world forward one tick and present to the surface.

GLFW + AWT = :(

GLFW does not play nice with AWT, especially on macOS where we have the requirement to run on the main thread. This is well documented including in this repo and will be an issue long term. Right now, I've chosen to just hard code disabling AWT when launching a sketch, but we'll need a more comprehensive solution here eventually.

How to test

Right now, I've only added support for macOS because I don't have my other machines to test on. But if you have a mac it should be pretty easy, just add a basic bevy scene to the app init. The next PR should implement our first basic actual rendering to test from Java.