I have been working on a 2D graphics library following the same API used in processing, its in Metal as OpenGL has been deprecated on MacOS for years.
I don’t know if there is any interest in integrating this into the main branch, but it’s not a lot of OpenGL to replicate in Metal.
FYI, many of the calls like noFill() are not documented in the reference page, I have only found them in examples.
I should be able to finish out most of the work in a couple of weeks, I worked on the OpenGL Framework at Apple for 10+ years and replicating the immediate mode vertex model shouldn’t be that hard to do in Metal. (while it won’t be as performant as VBO and stuff.. it will work fine)
It should be all accessible from C, so a FFI from Java should work fine. I am not a Java developer but it shouldn’t too hard to figure out.
Hi @guymadison WELCOME! That sounds awesome. I would love to check it out. We decided to create a shared rust library for processing to FFI. it’s built on wgpu. We did FFI using project panama in the Java ecosystem. Definitely check it out: GitHub - processing/processing4 at the-wgpu-moment
Would love to chat with you more about graphics though. We are also doing funny things in order to replicate immediate mode behavior.
Also thanks for pointing out the holes in documentation. I’ll ask about that, hopefully someone will be able to help add that in
Maybe WGPU is the way to move forward on this, I will definitely take a look at this. IIRC I looked at WGPU a couple of years ago and it was only intended for web applications and weakly supported in Safari at that time.
Maybe it’s because I am an OS programmer.. not an application programmer, but man that is a lot of code to wander through just to get a triangle out. I understand you have to choose a generic path to support all platforms, but jeez you can do a hello triangle in less than 100 lines of code in Metal. Just browsing the dawn code, which is in C++ not Rust I am pretty sure with WGPU you will see 2000+ lines of code walked through (if you include the WGPU to native interface) to do the same thing.
I know Khronos supports the SPIRV tools which convert to Metal / HSL / Vulkan and I have used them, the GLSL format used requires some changes to the generic input format that is used by older shaders but so do most modern API’s. You could still support GLSL shaders and a lot of fun stuff without all the overhead.
The benefit of WGPU is it works on everything, but the amount of code it takes to do what Processing actually uses is kind of daunting. My M4 mini with 64 GB of memory is still compiling the dawn source tree after 35 minutes.
I guess it’s your choice.
But there are simpler more performant options if you choose to go that route, if you want to discuss I am all in.