RepaintManager doesn't make sense in NEWT

9 views
Skip to first unread message

Mike Hogye

unread,
Dec 10, 2013, 2:52:28 PM12/10/13
to metsci-...@googlegroups.com
RepaintManager has a some "exec" methods that were useful in JOGL 1, when JOGL event handling and rendering were done on a single thread (usually the Swing/AWT/SWT thread). With NEWT, however, each canvas has its own event thread. And there are no guarantees at all about rendering threads -- there might be 20 different rendering threads, or there might not even be anything that fits the description "rendering thread."

At any rate, syncExec( ) and asyncExec( ) don't make sense with NEWT -- there is no particular thread on which a submitted runnable should run. As for the render-loop part of RepaintManager, we should probably just use JOGL Animators.

Furthermore, the non-NEWT stuff is so broken in JOGL 2 that NEWT is really the only viable option. There's no going back to a single event-and-render thread.

I propose that we try removing RepaintManager. This will cause compile errors ... but that's actually appropriate, because anything relying on the old repainter threading guarantees is already broken (even though it still compiles).

Geoffrey Ulman

unread,
Dec 10, 2013, 2:58:54 PM12/10/13
to metsci-...@googlegroups.com

Agreed. While we're removing RepaintManager, perhaps we should remove the older GlimpseCanvas implementations as well. As you point out, they have problems now and we're unlikely to support them further.

We could use the jogl2.1.2 branch for this. I haven't yet merged this back into master and made the release that I was thinking about. These changes are related...
Reply all
Reply to author
Forward
0 new messages