OpenGLContext issue

Hi, there is an issue in OpenGLComponent::OpenGLComponentWatcher.
Indeed, when window or component is minimized, the GL context is released by the following function :

    void componentVisibilityChanged()
        if (! owner.isShowing())

But when window/component is shown again, then the watcher does not restart the renderThread or recreate the GL context.
This is not visible with the demo because there is a timer which calls triggerRepaint() and force the creation of the new GL context.
Can you look at this ?

Well, the context should be recreated the next time a repaint happens, and I’m surprised that there isn’t a repaint when the window is shown…? Perhaps just this:

void componentVisibilityChanged() { if (! owner.isShowing()) owner.stopRenderThread(); else owner.repaint(); }

There is not repainting because of (I think!) the way you create the nativeWindow in OpenGLContext which is a nonrepaintingembedded…
Moreover, I think it is not a good idea to delete and create context like this, each time window is minimized or whatever, because we need to recreate all our GL stufs (when we use non-shared functions like generation of buffers…).

Well, hold on, because I’m in the middle of trying to re-think the whole GL system - I think it needs a radical restructuring, and all this code may get changed anyway.

You are? Huh. Well, FYI - I tried to change to use background threading OpenGLComponent rendering on Linux, and I’m having no joy - all my textures and buffers aren’t working (and DisplayLists).

The exact same code works on Mac, and on Linux when I make my own contexts. It’s a head scratcher - the context gets created, it seems to be shared (to get DisplayLists), all my buffers and textures seem to be created, but they don’t work. Other drawing - simple colored lines and rectangles work as expected.

I’m still digging, and I suspect it’s back to the thread <> displayConnection <> GLContext linkup, but it may also be some weird state thing.

Just FYI. I was about to try to use my own thread again, if the current code supports it. I’d definitely request that a new structure supports user supplied threads and context manipulations, on Linux.


Yes, that’s the kind of thing it’ll do. (But it’ll also need to support android, where it’s impossible to use your own thread!)

Ah, in terms of my problem, creating the Component to NOT allow subcomponents fixed the problem with VBOs and friends (which was masking whether local textures worked).

I’d say that your component code is leaving something like a VAR active that breaks other rendering? I reset most everything else.

Meanwhile, looks like context sharing on Linux (Nvidia GL) may still be borked, probably related to threads. Need to dig some more.