Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


#Actualfrob

Posted 13 November 2013 - 07:03 PM

It might use hardware acceleration, or it might not,  The problem is that the decision often seems random and it can change mid-execution, and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late. 
 
Some of the java graphics parts will take advantage of 2D hardware acceleration. Unfortunately they are tricky to get correct and they don't document which operations prevent the acceleration. That's why the general advice is to use JOGL or another library that ensures hardware acceleration.
 
Sometimes it decides to use OpenGL or DirectDraw graphics operations to accelerate it, sometimes it uses a very slow CPU processing to do the exact same operation. Sometimes one operation is accelerated but another is not, perhaps on one machine drawImage() is not hardware accelerated but copyArea() is accelerated. Then on the next machine drawImage() may be accelerated but copyArea is not. You never know what you are going to get.
 
 
JOGL is a wrapper for OpenGL. Using JOGL or one of the other similar libraries give much better results because you are no longer at the undocumented whims of the system. If you rely on Java's BufferedImage you get some of the benefits like streaming support, but it comes at a cost that it may be high performance or low performance at the system's whim, sometimes changing performance characteristics mid-use when an operation like GetRGB() is used. Contrast this with an OpenGL texture where you know it is a texture, and it has all the performance characteristics that come with it.

#1frob

Posted 13 November 2013 - 07:01 PM

It might use hardware acceleration, or it might not,  The problem is that the decision often seems random and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late. 
 
Some of the java graphics parts will take advantage of 2D hardware acceleration. Unfortunately they are tricky to get correct and they don't document which operations prevent the acceleration. That's why the general advice is to use JOGL or another library that ensures hardware acceleration.
 
Sometimes it decides to use OpenGL or DirectDraw graphics operations to accelerate it, sometimes it uses a very slow CPU processing to do the exact same operation. Sometimes one operation is accelerated but another is not, perhaps on one machine drawImage() is not hardware accelerated but copyArea() is accelerated. Then on the next machine drawImage() may be accelerated but copyArea is not. You never know what you are going to get.
 
 
JOGL is a wrapper for OpenGL. Using JOGL or one of the other similar libraries give much better results because you are no longer at the undocumented whims of the system. If you rely on Java's BufferedImage you get some of the benefits like streaming support, but it comes at a cost that it may be high performance or low performance at the system's whim, sometimes changing performance characteristics mid-use when an operation like GetRGB() is used. Contrast this with an OpenGL texture where you know it is a texture, and it has all the performance characteristics that come with it.

PARTNERS