nanovg for plugin uis

[0thTemple]

@syntonica
I had slightly blurry results from NanoVG, though not within VST and as severe as yours.
The culprit was the post-processing AA setting of the GPU driver.
Disabling this gave results more similar to your Cocoa example.



To those who are successfully using a modern OpenGL context + NanoVG in plugins:
What, roughly, does your Editor class look like?
A full example is probably not necessary, but hints are appreciated

I've tried a multitude of initialization / context management schemes,
and there is always some difficult-to-debug, inconsistent, host-dependent, time-dependent,
planetary-alignment-dependent behavior.

There is a GLFW fork, allowing window+context creation using the host-provided
window handle, which appears suitable for this purpose, which should in theory
take away much of the guesswork, but there still are many unknowns.

Logging every step of the way shows no obvious errors in either the native window
generation/subclassing, the raw gl context (if self-made) or managed glfw window/context (if using that),
nor the NVG contexts.

I'm familiar enough with writing typical windows/gl/vst code separately, still
I thought I'd ask, rather than start the endless blind wandering yet again.

[mystran]

I've tried a multitude of initialization / context management schemes,
and there is always some difficult-to-debug, inconsistent, host-dependent, time-dependent,
planetary-alignment-dependent behavior.

OpenGL context management is actually quite simple: always explicitly set the active context whenever you are about to do something with OpenGL and always restore the previously active context whenever you are done. The "inconsistent, host-dependent" problems generally happen when you either fail to set the current context somewhere, or you fail to restore the previously active context and the host doesn't bother checking.

[hibrasil]

I am using MetalNanoVG successfully

https://github.com/ollix/MetalNanoVG

the metal view, behaves just like a normal nsview pretty much, didn't have to do any faffing around

check out PUGL for a GLFW like plugin solution for OpenGL

https://drobilla.net/software/pugl

[0thTemple]

PUGL might be viable, save for a few issues (granted, I only briefly checked its capabilities)

• [1] It does not appear to support modern GL contexts, relying instead on some self-defined subset of legacy GL.
  [2] A fresh, unmodified build of the standalone pugl_test fails to draw anything, even glClearColor is not shown.

The latter issue is probably trivial, but I'm unlikely to spend any time solving it (or testing embedding it in a vst) given the first.
There is no issue at all creating a legacy context/window/etc myself. It's simply not useful to do so.
Abstracting this to a library saves me no effort, I would have to rewrite large parts of it anyway.

The GLFW branch is closest to functional, just no easier to debug.

There is some mystery sauce required to manage a modern context in a vst.

[mystran]

Personally I find that the "path of least resistance" is to just create and manage your own OpenGL context yourself.

On Windows, assuming you can get a context up and running, when entering any code that uses OpenGL, you call wglGetCurrentDC and wglGetCurrentContext and store the HDC and HGLRC they return. Then call wglMakeCurrent with your own DC and HGLRC. Then you can do whatever you please with OpenGL and finally you call wglMakeCurrent again, this time with the HDC/HGLRC from the host that you stored.

As long as you do this consistently it'll work perfectly fine in any host whether or not the host or some other plugins are using OpenGL or not. If you have OpenGL code scattered in a bunch of places, the most straight-forward approach is to wrap this logic into a RAII object and just create one of those whenever you want to touch OpenGL.

For macOS the logic is basically the same except you fetch the currentContext property of NSOpenGLContext and use makeCurrentContext on the context objects to switch between them.