2700 = Windows, 60-70 = Linux perhaps? You may want to try explicitly turning on the OpenGL pipeline to see if that changes anything.

But you have also run into Java2D's major downfall and one of the primary reasons why people tend to avoid it in favor of LWJGL or JOGL - the API is highly unpredictable and it is across not only platforms, but also hardware and even minor versions of Java :s You can't even really call it an API as an API is supposed to hide implementation details; with Java2D you *must* know what is going on under the hood in order to get any kind of performance out of it.

That being said, you can turn on trace logging to see what drawing calls Java2D is doing under the hood; with that logging you can see if it is using the hardware pipeline or the software pipeline.

2700 = Windows, 60-70 = Linux perhaps? You may want to try explicitly turning on the OpenGL pipeline to see if that changes anything.

But you have also run into Java2D's major downfall and one of the primary reasons why people tend to avoid it in favor of LWJGL or JOGL - the API is highly unpredictable and it is across not only platforms, but also hardware and even minor versions of Java :s You can't even really call it an API as an API is supposed to hide implementation details; with Java2D you *must* know what is going on under the hood in order to get any kind of performance out of it.

Vast majority of that code looks like it's a non-Java2d software renderer though. Only bit of Java2d looks like the buffer strategy. Pure Java software renderers tend to be quite similar performance across VM's. More likely with those figures is that one of the canvas buffer strategies is vsynced.

@nsigma:I swapped the code to use BufferedImage but only lost performance. In my code bitmaps are arrays of int, so drawing is in fact done on arrays and I blit my screen (Screen class) every render on the physical screen. Can that be a bottle neck?

@cylab:CPU usage: core1: 60-80%, core2: 40-50%, cores3-8 are under 5%What should I do with VSync? Is there a way to turn it off (would I get screen flickering then)?

Yeah when you only do manual drawing stuff in stead of blitting primitives the performance is likely better when using the software pipeline. (forced) vsync seems like a candidate to explain the results; it may be that it is enforced because OS drawing functions are used (X11FillRect). Not to familiar with Linux / X11, I can only make haphazard guesses there.

> I swapped the code to use BufferedImage but only lost performance. That will probably depend on if the BufferedImage is a "compatible" image or not. Transparency can also be a bottleneck.

I swapped the code to use BufferedImage but only lost performance. In my code bitmaps are arrays of int, so drawing is in fact done on arrays and I blit my screen (Screen class) every render on the physical screen. Can that be a bottle neck?

Think you missed the point of mine and cylab's comments - if it's caused by VSync you don't have a performance bottleneck across the two OS's. VSync is good, as it will stop tearing and it's pointless running faster than the screen can update anyway. If you just want to check the performance of the code across the two OS's, try taking out the blit to screen and just running the rest of your code - they'll almost certainly come out about equal performance.

Unless you can take advantage of Java2D hardware acceleration, working directly with arrays of int is often faster than using the Java2D software renderer. It's the same mechanism I use in the optimized software renderer for Praxis, and I use LWJGL and some code forked from libGDX for the OpenGL renderer (all of which you can read as Java2D is often a PITA! )

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org