Posted by Peter F on Oct 12, 2017; 3:38pm
URL: https://forum.jogamp.org/Handling-window-events-when-using-a-dedicated-OpenGL-thread-tp4038251.html

Hello,

I've been converting my program from one threading model to another & have some questions about some behaviour I'm getting regarding window events.

My Question:

The window is no longer automatically prompted to repaint on window events such as when another window moves over mine ( the buffer is left contaminated with the window that moved over it ), I can no longer close the window using the X icon and resizing the window does not result in a call to GLEventListener.reshape(..).

I gather this is because I have the GLContext current on a Thread of mine on a permanent basis ( see background below for more info ) and the NEWT EDT is waiting on it to become free? When I tried releasing the context for other threads then window closing & resizing worked again - but the window could still be contaminated by other windows moving over it, so I'm still missing something here.

How should I interact with window events like these when running with a dedicated OpenGL Thread? Does JOGL/NEWT have one that I should be using instead?


Background Info:

My old model was one where a task executor would fire based off a Thread Pool using scheduleRunnableAtFixedRate with a target FPS rate. This runnable would do a full cycle of executing UI events, animations and then executing all rendering code with the GLContext made current. At the end of the cycle it would release the GLContext - free until the next execution.

My new model uses a dedicated Thread from a pool, with the GLContext made current permanently to save on the context switching overhead. This GL task thread uses a LinkedBlockingQueue to receive tasks from other threads ( loading, unloading, rendering on/off screen etc ).

The idea is that I can have other UI threads handle events, long processes, handle non-GL related updates etc & then post synchronous or asynchronous tasks to the OpenGL Thread - depending on the situation. This frees the GL thread to only run GL related code.

It also enables me to buffer a batched, optimised set of rendering calls on a non-gl thread to pass to the OpenGLThread as a task when it's ready - while the OpenGLThread is drawing the frame previously submitted & doesn't have to optimise the frame itself - all it has to do once the app is loaded is execute batch optimised draw tasks.


I hope this has made some sense - I'm open to any ideas / concerns about my newer model - I imagine its something you've all seen before & any pointers are welcome!

Kind regards & thanks,

Pete.