Captain's Log: Stardate 78198.7

Today was... "fun." I was hoping to get a basic prototype working (i.e. the "draw a triangle hello world") for the new 3D rendering engine using Google Filament, but things turned out to be a lot more complicated than I expected. The fundamental problem comes down to the fact that JUCE is not designed for extensibility in terms of renderers, at least not in the way I need.

At the OS level, Windows and Mac are similar in that you do some black magic to create a window handle (HWND on Windows, NSView on Mac), and then you can create a swap chain for that window and begin using a rendering API like OpenGL, Vulkan, Metal, etc. In the case of Filament, the specific API is abstracted, so you just give Filament the swap chain and it handles the rest of the setup.

However, JUCE internally does all this, and sets up its own swap chain and rendering threads, etc. And the problem is that it does not expose any way to get access to its internal swap chain. So you can't just grab the HWND for the main JUCE window and start drawing to it.

Now, it is possible to swap things out and do it yourself, because juce_OpenGLContext does exactly this. But it's a seemingly huge project -- the JUCE OpenGL stuff is at least a few thousand lines of code, which I'm not super excited to try to replace. But I might have to?

I'm exploring some other options. The first thing I tried was to create a second native OS window which the 3D graphics would be drawn in, and which would be placed above the JUCE window in the right spot. I think this might work, but the problem is that things like JUCE menus, etc, are obscured by the second window in a way that can't be fixed.

Another possibility is to put the JUCE GUI in a native OS window above the 3D graphics. But this requires transparency in the JUCE GUI OS window, which may be possible but AFAICT it would mean Linux support is out the window. And also it might be slow.

Tomorrow I'm going to have to spend some time really digging into how JUCE does OpenGL, to see if there's some way to use the same technique but without the same degree of complexity.