Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] Using OpenGL from different Thread

Hi,

i would like to discuss some Feature that i miss:
Rendering outside the SWT/GUI-Thread.

I have some JOGL experience. In JOGL, there was something called
"AnimatorThread". All GLEventListeners (that means: all calls to
OpenGL-methods) took place within that Thread. All OpenGL-related Events
from the SwingThread were transported to that Thread too. (like resize etc.)

The Swing-Thread was not blocked by the rendering process. (Just imagine
your have something like 3fps - imagine how slow your regular Swing GUI
would be)

There was also something called "SingleThreadWorkaround" because of some
bad ATI drivers. With that workaround, all the OpenGL-Code was executed
within the SwingThread again. Even if you were using an AnimatorThread.
Actually i had no problem with ATI cards.
In JSR231, it's even more complicated. The code is sometimes executed
within the AnimatorThread and sometimes executed within the SwingThread.
JOGL does the sychronizing and "context switching".


So as far as i know, something like this is not possible with SWT at the
Moment.

As far as i know, OpenGL works the following way: i mark an OpenGL
context to be the current one for the current Thread. Then i can issue
the OpenGL commands and then swap the buffers. The context can be used
by one Thread at once. The context can not be the "current context" for
two Threads at once.

With SWT's GLCanvas implementation, all calls to GLCanvas.setCurrent()
or GLCanvas.swapBuffers() throw an Exception if they are not called from
the SWT-Thread for that component. So my tries to implement a
RenderingThread failed so far :-(

Of course, if it would work, i would have to move all the OpenGL-Code
from the SWT-Thread to the my own RenderingThread. I already have easy
mechanisms for that. So to me, this doesn't seems to be a problem.
All the workarounds and synchronizes from JOGL are maybe not even
necessary for SWT. Actually i wouldn't even expect, that SWT does all
the work like moving the events from one to another Thread.


What i don't know: does the OpenGL-API support such things? And if it
seems so, could you imagine to weaken the restrictions of the GLCanvas,
so that the methods can be called from outside the SWT-Thread?


Thanks,

  Sven

Attachment: signature.asc
Description: OpenPGP digital signature


Back to the top