Onscreen vs offscreen performances

Hi,

I've been trying Java 3D 1.6.0 / JOGL 2 with an onscreen Canvas3D instance then, with an offscreen JCanvas3D instance, but didn't notice some performance difference on my iMac. Aren't onscreen canvases supposed to run faster (i.e. have a higher frame rate)? If yes, in which case? If not, isn't it better to always use offscreen canvases in a Swing program to avoid mixing heavyweight and lightweight components?

Thanks for your recommendations...

I'm vaguely recalling from when August did the osx work that it essentially forced offscreen FBO use, even in the onscreen case, so it's very possible on OSX there is no disadvantage to using the JCanvas3d as there's going to be a copy from the offscreen FBO anyway.

Harvey

Harvey is right, it's true for Java3D in general and especially under OS X. When you use JCanvas3D, most of the rendering is done offscreen anyway.

However, onscreen rendering in general is faster. The difference of performance depends on the hardware and the driver. Offscreen rendering is noticeably slower on Intel chipsets in lots of cheap laptops and desktop computers, it is very buggy on some hardware whereas there isn't a big difference between onscreen and offscreen rendering with up to date drivers and "not very old" Nvidia graphics cards.

If you want to get better performance, avoid offscreen rendering at all cost but it is almost impossible under OS X while we have no solid UI toolkit for NEWT (this is in our plan...). If you switch to NEWT, you'll have to replace Java3D by another scenegraph supporting it, for example Ardor3D, JMonkeyEngine 3 or Xith3D.

Thanks for advices.

So julien, if I follow you, using Java 3D under Mac OS X will give the same performances with Canvas3D and JCanvas3D, right?
Was the offscreen FBO forced only from Java 3D 1.6, or was it forced in Java 3D 1.5.2 too?  

On 11/10/2013 01:55 PM, Manu [via jogamp] wrote:
> Thanks for advices.
>
> So julien, if I follow you, using Java 3D under Mac OS X will give the same
> performances with Canvas3D and JCanvas3D, right?
> Was the FBO forced only from Java 3D 1.6, or was it forced in Java 3D 1.5.2
> too?  

The JOGL story ..

On OSX >= 10.6 (?) w/ Java7 all AWT related resources must use FBO offscreen
rendering, i.e. GLCanvas and even NewtCanvasAWT.
Here a shared GL context is used for compositioning the FBO texture
w/ the 'global' CALayer using OpenGL.

GLJPanel uses an offscreen FBO as well, however compositioning is performed
using Java2D .. and hence might be slower (for bigger screens).
Further more .. we have to flip the image using GLSL or memory copying.

I will add a flag in GLJPanel to allow users to skip the vertical flip,
so users need to take care of the vertical orientation themselves ..

Pure NEWT would allow to have an onscreen drawable, as Julien described.

Java3D uses JOGL .. but I don't know the details (GLCanvas or GLJPanel).

Hope this overview helps a bit.

> Emmanuel Puybaret
>

JCanvas3D is a JPanel that uses both an internal Canvas3D and a BufferedImage. Canvas3D is an AWT Canvas that uses a GLCanvas (created by using a JAWTWindow and the native window factory) if onscreen otherwise it works a bit like JCanvas3D. Java3D uses JOGL windowing very poorly, any scenegraph using our canvases a lot more straightforwardly can get better performance, even Xith3D (but this one is almost no longer maintained or its activity is extremely low). Keep in mind that Java3D 1.5.2 had to support several "pipelines" including some of them not based on JOGL which leaded to poor design choices and when I started porting it to JOGL 2.0, it was already difficult to keep the public API unchanged, I couldn't rewrite Canvas3D and JCanvas3D from scratch.

If the JogAmp community could port PureSwing or something equivalent to JOGL 2.x, we could port Swing based applications to JOGL + NEWT.