Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java2D Slow with Integrated chips (windows)  (Read 2947 times)
0 Members and 1 Guest are viewing this topic.
Offline StumpyStrust
« Posted 2012-07-18 22:46:25 »

I think that java2D gets really fill rate limited when using the d3d pipeline on integrated chips.

For example: my laptop has optimus and never seems to use its dedicated gpu. When I run my particle editor, it can render 1k+ particles fine as long as they are small sizes 1-5 pixels. The moment you try rendering an image above 300 it drops to a screeching halt. When using the opengl flag, it performs how it should and does not seem to be fill rate limited. I do not know what java uses on macs but I think there might also be an issue there.

If others out there could test this maybe that would be sweet. By test I mean try rendering multiple images with and without the opengl global flag set and see if there is a difference in performance.

Please don't just screem out, "Java2D sucks buttox! Use a REAL graphics library like idk opengl"

Offline davedes
« Reply #1 - Posted 2012-07-19 03:15:15 »

Here's my own benchmark.

iMac 10.6.6 with an Intel Core 2 Duo (3.06 GHz), OpenGL 2.1 and NVIDIA GeForce 9400
Tests run in 800x600 windowed mode

Java2D @ 60 FPS
32x32 RBA ~ 1,300 sprites
32x32 RGBA scaled to 256x256 ~ 38 sprites (uses getScaledInstance and SCALE_FAST)
256x256 RGB ~ 135 sprites
512x512 RGBA ~ 4 sprites

Java2D @ 60 FPS with "-Dsun.java2d.opengl=true"
- No change

For comparison, Slick2D @ 60 FPS
32x32 RBA ~ 18,500 sprites
32x32 RGBA scaled to 256x256 ~ 400 (uses getScaledCopy and FILTER_NEAREST)
256x256 RGB ~ 300
512x512 RGBA ~ 53

The Slick test was arguably easier to write, and certainly more compact. Will provide source shortly...

Java2D reliability and performance sucks, plain and simple.


EDIT: Source. Feel free to nitpick it and optimize it.
Java2D
Slick2D

Offline 65K
« Reply #2 - Posted 2012-07-19 06:31:04 »

Java2D is ok to use, that flag obviously not: on my computer it results in empty black windows when enabled, no matter which Java application.
So be careful when shipping anything with the flag enabled.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #3 - Posted 2012-07-19 06:50:50 »

My work computer (using davedes's java 2d code) gives:

Java2D @ 60 FPS
32x32 RGB ~17000 sprites
256x256 RGB ~865 sprites (uses getScaledInstance and SCALE_FAST)

32x32 RGBA ~15500 sprites
256x256 RGBA ~1600 sprites (uses getScaledInstance and SCALE_FAST)

The graphics card is not itegrated, however it is not a fast 3D accelerator card either... so take these figures how you will Tongue


------------------
System Information
------------------
Time of this report: 7/19/2012, 16:07:57
       Machine name: XP060705
   Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.120504-1619)
           Language: English (Regional Setting: English)
System Manufacturer: Dell Inc.
       System Model: Precision WorkStation T3500 
               BIOS: Phoenix ROM BIOS PLUS Version 1.10 A08
          Processor: Intel(R) Xeon(R) CPU           W3530  @ 2.80GHz (8 CPUs)
             Memory: 3582MB RAM
          Page File: 2211MB used, 3249MB available
        Windows Dir: C:\WINDOWS
    DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
     DxDiag Version: 5.03.2600.5512 32bit Unicode


---------------
Display Devices
---------------
        Card name: NVIDIA Quadro FX 1800
     Manufacturer: NVIDIA
        Chip type: Quadro FX 1800
         DAC type: Integrated RAMDAC
       Device Key: Enum\PCI\VEN_10DE&DEV_0638&SUBSYS_062C10DE&REV_A1
   Display Memory: 768.0 MB
     Current Mode: 1280 x 1024 (32 bit) (60Hz)

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2012-07-19 08:49:46 »

Please don't just screem out, "Java2D sucks buttox! Use a REAL graphics library like idk opengl"
And yet it must be said that this is precisely why LWJGL was developed in the first place...

Cas Smiley

Offline StumpyStrust
« Reply #5 - Posted 2012-07-19 13:58:49 »

Ehh I guess java2D just sucks.  Tongue

Quote
Java2D @ 60 FPS
32x32 RGB ~17000 sprites
256x256 RGB ~865 sprites (uses getScaledInstance and SCALE_FAST)

32x32 RGBA ~15500 sprites
256x256 RGBA ~1600 sprites (uses getScaledInstance and SCALE_FAST)

Do you mean that there are 17000 non scaled sprites and 865 scaled sprites at once? or one test with 17000 and one with 865?

I still think jav2d is not crap. It is good for small games/applications as long as you keep things simple. But yes, lwjgl is the way to go to get good performance.

Offline StumpyStrust
« Reply #6 - Posted 2012-07-19 15:44:23 »

So i played with your test code a bit and was very surprised. Most of what you did was the fastest way of doing things and there was nothing to complain about but the interesting thing i found out was how fillrate limited java2D really is.

For example: 256*256 30fps 2k sprites. Drop it to 128*128 200+ fps. Also, scaling instead of before hand but when the balls were called to render, did not change the performance. Everyone says scaling like that is big fps drop. I see no difference what so ever.

1  
g.drawImage(sprite, (int)balls[i].x, (int)balls[i].y,128,128,null); //<---should be slower


then

1  
sprite = sprite.getScaledInstance(128, 128, Image.SCALE_FAST); //<--- doing it before hand


Another thing I found odd any maybe someone with more experience can explain it to me but why does using transparency like this

1  
2  
Graphics2D g2d = (Graphics2D) g.create();
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, .1f));


Make things fast and not slower? Is it because the lower the transparency the less pixels have to be drawn? The lower I make it the faster things run. At .1 I get 2k 256*256 at 90 fps. I am really lost now as I thought alpha was a killer in performance.

Offline deepthought
« Reply #7 - Posted 2012-07-19 15:53:20 »

when you start having to rotate things in java2d you'll definitely want to find something else.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline theagentd
« Reply #8 - Posted 2012-07-19 16:01:48 »

256x256 x 1600 = 104.8576 million pixels.
At 60 FPS: 6.291456 gigapixels per second.

My GTX 460M has a THEORETICAL fillrate of 5.4 Gpixel/s.


I have a fully GPU accelerated particle engine which renders particles as transparent untextured square points. The particles bounce on the screen edges (it's in 2D), but they are treated as 1 pixel points, meaning that they'll only bounce when half the particle is already outside the screen. This "increases" fillrate since that part is clipped, and is especially noticeable with larger particles. That combined with the increased number of vertices to process reduces performance as the particles become smaller.

Gpixel/s = numParticles * particleWidth * particleHeight * 60 / (10^9)

64x64 particles: 20 000 particles = 4.9152 Gpixel/s.
32x32 particles: 70 000 particles = 4.3008 Gpixel/s
16x16 particles: 230 000 particles = 3.5328 Gpixel/s.
8x8 particles: 750 000 particles = 2,8800 Gpixel/s.
4x4 particles: 1 750 000 particles = 1,6800 Gpixel/s.
2x2 particles: 2 400 000 particles = 0.5760 Gpixel/s.
1x1 particles: 2 750 000 particles = 0,1650 Gpixel/s.


If the above (256x256) result is with Java2D I'll be surprised. Either:
1. a big number of the particles are outside the screen and get clipped,
2. you have a pretty powerful graphics card and Java2D has perfect OpenGL acceleration

It's definitely not impossible though. With only 1600 particles the CPU cost of even glBegin/glEnd might be low enough to allow 60 FPS, so Java2D might be able to handle it even if it's not very CPU effective. The hardware can handle it, just look at a GTX 680:


32.2 Gpixel/s... *drool*


@StumpyStrust
Scaling images (textures) is hardware accelerated. Up-scaling it even with bilinear filtering should be free and faster than upscaling it and storing it in memory, since your GPU needs to read less texture memory. Transparency is also often free on newer GPUs since the blending is also handled by dedicated hardware. I have no idea why it gets faster with lower transparency. Your GPU should do the exact same work no matter what alpha value you have.

Myomyomyo.
Offline StumpyStrust
« Reply #9 - Posted 2012-07-19 18:52:00 »

Quote
Scaling images (textures) is hardware accelerated. Up-scaling it even with bilinear filtering should be free and faster than upscaling it and storing it in memory, since your GPU needs to read less texture memory. Transparency is also often free on newer GPUs since the blending is also handled by dedicated hardware. I have no idea why it gets faster with lower transparency. Your GPU should do the exact same work no matter what alpha value you have.

This is exactly what I thought but everyone always said different.  Angry

Here is a video showing what I mean by faster more transparent.  Huh

https://www.youtube.com/watch?v=3xigLAwKJhw

(how do you embed videos?)

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2012-07-19 19:02:45 »

The more transparent you make the draw, the more pixels will be completely transparent at the edges, and they are therefore not processed at all. Seems to imply software rendering though.

Cas Smiley

Offline theagentd
« Reply #11 - Posted 2012-07-19 22:39:53 »

The more transparent you make the draw, the more pixels will be completely transparent at the edges, and they are therefore not processed at all. Seems to imply software rendering though.

Cas Smiley
Wait, does SRC_OVER simply subtract (or add) that amount of alpha from/to each pixel? If so, it does imply software rendering like Cas said, since invisible and fully opaque pixels don't require any blending.

Myomyomyo.
Offline StumpyStrust
« Reply #12 - Posted 2012-07-19 22:49:12 »

The source is composited over the destination (Porter-Duff Source Over Destination rule).
        Fs = 1 and Fd = (1-As), thus:

        Ar = As + Ad*(1-As)
        Cr = Cs + Cd*(1-As)

From java docs.

If it is just software rendering, isn't it too fast?

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (15 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!