1.

Why Using Swing For High Performance Is Not A Good Idea ?

Answer»

First, all this inherents all arguments from 'Why using AWT for high performance is not a good idea 

Second, it involves compositioning using different methods, some may not be available on some platforms.

From fast to slow:

1.) External Java2D's GLContext and FBO object. 

  • GL stuff HW accelerated.
  • Available on some platforms: Linux/Windows Sun's Java2D impl.
  • Setup with System property 'sun.java2d.opengl' to 'true'.
  • Renders directly into Java2D's FBO object, if available. 

2.) Own PBuffer GLContext, which has to be composed.

  • GL stuff HW accelerated.
  • Available on most platforms: No dependency to Java2D implementation.
  • Renders into an own offscreen drawable, and copies it over to AWT's BufferedImage.

3.) Own Pixmap GLContext, which has to be composed.

  • GL stuff unlikely hw accelerated.
  • Available on most platforms: No dependency to Java2D impl.
  • Renders into an own offscreen drawable, and copies it over to AWT's BufferedImage.

As you see, no straight forward HW RENDERING is involved, assuming that even the windowing manager is using offscreen SURFACES - you would have 2 compositions here already.

At least (1) would be 'acceptable' here, if available, but if only (2) is available - the performance would not match the STATE of the art!

Sure, it might be enough for some UIs or static pictures .. or so, OTHERWISE, I would prefer the 'overlay' method, ie using a GLCanvas within a Swing COMPONENT, while no menu is being shown.

However you do it .. the generic AWT 'restrictions' apply here as well.

First, all this inherents all arguments from 'Why using AWT for high performance is not a good idea 

Second, it involves compositioning using different methods, some may not be available on some platforms.

From fast to slow:

1.) External Java2D's GLContext and FBO object. 

2.) Own PBuffer GLContext, which has to be composed.

3.) Own Pixmap GLContext, which has to be composed.

As you see, no straight forward HW rendering is involved, assuming that even the windowing manager is using offscreen surfaces - you would have 2 compositions here already.

At least (1) would be 'acceptable' here, if available, but if only (2) is available - the performance would not match the state of the art!

Sure, it might be enough for some UIs or static pictures .. or so, otherwise, I would prefer the 'overlay' method, ie using a GLCanvas within a Swing component, while no menu is being shown.

However you do it .. the generic AWT 'restrictions' apply here as well.



Discussion

No Comment Found