Minimizing delay between GLCanvas.repaint() and display()

Hello,

I have an application with a main thread that fires GLCanvas.repaint() at appropriate times when all the model data is ready to be rendered. However, I have noticed that there is a very long delay (hovers around 20ms) before display() is eventually called on my Canvas. The display method takes about 9ms and then finishes. This causes my whole frame to be 29ms, when I only spend 9ms in display.  I know it still has to swap buffers and VSync but this time frame still seems very long.

I assume this is because AWT is scheduling the paint for a time it thinks is appropriate? I'm not using any Swing, just drawing to a canvas, and it's all done on one thread. I'm not using an Animator.  Turning off VSync (presumably by calling setSwapInterval(0)) has no effect. Though, I do want the frames to be VSynced.

Since I am using no Swing, my initial instinct was to call setRenderingThread() to try to prevent AWT from doing any scheduling and manage the display update myself. Though I read in here: http://download.java.net/media/jogl/doc/userguide/ that it is not recommended and possibly even entirely disabled.  I suppose AWT is still needed for resizing the window or things like that, so maybe that is why.

Either way, can anyone help explain what may be causing this delay, and how best to avoid it?

Hi

You should rather create a custom animator in order to render on demand.

Thanks for the response.  Just some follow up questions.  I can write a custom Animator but don't want to cause instability, and want to be sure it will resolve the problem.

- When I use the Animator class to do the rendering instead of calling repaint() manually, it still just creates an AWTAnimatorImpl and calls display through the EDT causing the same delay.  So, I will need to create a whole new animator *not* derived from AnimatorBase?  All I really need to do is call display() and then swapBuffers(), is an animator necessary? Will it really make things faster?

- I tried turning off automatic buffer swapping and calling swapBuffers manually, so I could profile it. Turns out swapBuffers is actually taking 13ms of this 20ms. This seems unusually large.  Profiler is telling me it's 100% coming from jogamp.nativewindow.windows.GDI.SwapBuffers(long).  Is that really just how long it takes to swap the buffer? Even with a new animator, will I still be saddled with 13ms of buffer swapping?

Thanks for your help. I didn't want to go making a new animator class if in fact it is not the source of the problem.

Jesse

On 11/04/2013 06:14 PM, Jesse [via jogamp] wrote:
> Thanks for the response.  Just some follow up questions.  I can write a custom
> Animator but don't want to cause instability, and want to be sure it will
> resolve the problem.

Well .. stability implies things get done on the AWT-EDT
for AWT components including GLCanvas.

The delay you experience is due to AWT-EDT's probably filled Runnables
or events ..
That is something we refer to AWT I/O blocks rendering in <http://jogamp.org/jogl/doc/NEWT-Overview.html>.
So you only choice for a higher responsive system here is to use NewtCanvasAWT,
i.e. NEWT in conjunction with AWT.

~Sven

Thanks Sven, this sounds like what I am after. I will implement the canvas using NEWT and reply back with results!

Jesse

Okay I got the application running using the NEWT canvas. Looks like there is actually a pretty significant performance improvement! A bit surprised since I was doing very, very little in the AWT callback methods (mousePressed etc), just assigning a variable, so I wouldn't have thought that the blocking IO would cause such a slowdown. But, apparently it does.

Just a few comments:

- Disabling focus traversal so I can manually handle tab events seems like I have to wait until the first call to display() since that's when the newt child + FocusTraversalKeyListener are attached, is there a callback or something I can set during initialize that I am missing?

- No way to only setMousePointerVisible for just the canvas, only the whole window (as far as I can tell?)

- Freeze when calling requestFocusInWindow() on the canvas directly from input, (looking at the source it seems like this is just not supported), maybe want to override that method and assert false / direct users to the appropriate method? Just a thought.

- Very excited about confineMouse, hoping this means I can throw away my robot implementation of this!

Thanks again for the help.

Jesse