Ah yes, this is probably a safe bet. However the pattern does seem to vary a little.
In source/blender/draw/intern/draw_manager_shader.c, WM_opengl_context_activate is called after context creation.

comp->gl_context = WM_opengl_context_create();
comp->gpu_context = GPU_context_create(NULL);
GPU_context_active_set(NULL);

WM_opengl_context_activate(DST.gl_context);
GPU_context_active_set(DST.gpu_context);

Though ensuring this context is active prior to GPU Context creation appears to make more sense, to ensure the backing OpenGL context is active before resources are created. Should be reasonable to modify the code accordingly.

From testing, adding a WM_opengl_context_activate(comp->gl_context) before GPU_context_creation fails on the assertion:

BLI_assert(GPU_framebuffer_active_get() == GPU_framebuffer_back_get());``` due to having no valid GPU context active at the time.

```void WM_opengl_context_activate(void *context)
{
  BLI_assert(GPU_framebuffer_active_get() == GPU_framebuffer_back_get());
  GHOST_ActivateOpenGLContext((GHOST_ContextHandle)context);
}

As DRW_opengl_context_release() called above disables the active GPU_context, which is later restored in the call to: DRW_opengl_context_activate

Given the code does not immediately require usage of the newly created GPU_context, then perhaps this is not a problem as-is. However, if we did want to ensure the backing GL context was active during context creation, then we could:

1. Skip the default framebuffer assertion in WM_opengl_context_activate if there is no valid GPUContext active.

2. Call GHOST_ActivateOpenGLContext directly, though this perhaps feels a bit messy as it opens the door for multiple ways of doing the same thing.

Or, please let me know if there is an alternative preferred approach for this.

Thanks!

I think we can leave the code as is then for this patch.

Not sure what exactly the plan is for Metal contexts, but in general this code should be refactored at some point. Removing "opengl" from the names, consistent order of creation/activation, platform consistency so we don't need #ifndef _WIN32 and better comments explaining the different types of contexts and how to use them. But that's beyond the scope of this patch.