[Desktop / GLFW] Features proposal : untethered context creation and OpenGL Compatibility Profile.

[tcoppex]

Hello everyone,

For a project I needed to access the last features of libVLC 4.0 that runs its instance on a separated thread with a shared OpenGL context.

Two issues arised :

1. libVLC requiered an OpenGL Compatibility Profile where OpenFrameworks is bound to Core Profile¹.
2. Window creation links² the window to the windowApp map and make its context current on the main thread every frame³, breaking the context when used simultaneously in another thread.

References :

• 1 : Forced Core Profile on OpenGL 3.2+. https://github.com/openframeworks/openFrameworks/blob/ce1bbc751595881398934e82029d74fe099899c5/libs/openFrameworks/app/ofAppGLFWWindow.cpp#L200
• 2 : Tethered GLFW window / context creation. https://github.com/openframeworks/openFrameworks/blob/ce1bbc751595881398934e82029d74fe099899c5/libs/openFrameworks/app/ofMainLoop.cpp#L68
• 3 : Main thread preempting the window context every loop. https://github.com/openframeworks/openFrameworks/blob/ce1bbc751595881398934e82029d74fe099899c5/libs/openFrameworks/app/ofMainLoop.cpp#L147

Proposed implementations :

The workarounds are simple and supposedly break-free.

For the first case, we can add a boolean flag in ofGLFWWindowSettings to use GLFW_OPENGL_COMPAT_PROFILE instead of GLFW_OPENGL_CORE_PROFILE.

For the second case, we can either create an ofCreateContext function or add a boolean in settings (eg. useCustomThread) that pass ofMainloop.cpp#L68.

Here is an example that set off every graphics presenting capabilities, unasked for in a windowless context :

shared_ptr<ofAppBaseWindow> ofCreateContext(const ofWindowSettings & _settings) {
  ofGLFWWindowSettings settings(_settings);
  settings.doubleBuffering = false;
  settings.visible = false;
  settings.setSize(1, 1);

  shared_ptr<ofAppGLFWWindow> context = std::make_shared<ofAppGLFWWindow>();
  
  context->setup(settings);
  context->setVerticalSync(false);

  return context;
}

Any thoughts on this ?

[tcoppex]

For completion's sake here is a related forum's thread https://forum.openframeworks.cc/t/experiments-with-vlc-based-video-player-help-needed/32451

[dimitre]

Great! I think from what you are saying the changes are minimal and it seems harmless to any other contexts. More than that IMHO it would be great to see ofVLCVideoPlayer in the core in the future.

[tcoppex]

For info libVLC just fixed its Compatibility Profile requirement (see https://code.videolan.org/videolan/vlc/-/merge_requests/1299), so this proposals become quality of life rather than mandatory for this particular third party.