[quote] Here’s my entry; arrows to walk around:
http://www.geocities.com/nonnus29/javademo2/demo.htm
[/quote]
On Mac OS X 10.3.2 JRE 1.4.2_03 on a Powerbook 1GHz PPC G4
you ready?
FPS maxed out at eleven (11). There was an issue with the screen flashing all white, I think when hitting an obstacle. low FPS was all teh way down to 3 or 4.
35fps with nonnus29’s thingie 
k7 500/128mb/gf2mx/1.4.2_03
win98se
Installed for 215wks 4days 9hrs 22mins 56secs (25/12/99)
Uptime: 1day 4hrs 39mins 41secs
So… imo it’s ok. Doing the same thing in any other language won’t be faster… blitting in VRAM… read back… transparent software blitting… and back to Vram - that is 
zparticle: nice tiles!
alpha 24 fps - 866 p3, on board gfx
non alpha; max was 60 dipped to 35 when scrolling. I’m going to check your code to see what you did differently…
Thats very worrisome about the mac osX performance!
Note: in my code I use the BufferedImage…getData method to get an int[] for the backbuffer BufferedImage which I drawImage onto the BufferStrategy gc every loop, but I only get the int [] once at the beginning then keep modifying the array. Just wanted to point that out from Abuse post. Probably a unmanaged, nonvram image is good in this case.
Still waiting for hardware accelerated smack down princec!
[quote]MY entry:
http://www.scottshaver2000.com/files/scroller.zip
Unzip it and use the run.bat file under Windows…
[/quote]
A whopping six and a half (6.5) FPS on Mac OS X 10.3.2 JRE 1.4.2_03 Powerbook 1GHz… using 800x600 16 bit
The peak was 10, the low 2… not very impressive, and not playable really. And I’m deducting points for your code “issues”. I like executable jars :).
Although this one did run in fullscreen mode (the previous example only ran in a window).
Heres your 300 blended sprites:
http://www.geocities.com/nonnus29/javademo2/demo300.htm
Runs ~20 fps on my old comp.
Changed the rectangles to actual snowflakes and fixed it so the objects only update positions at a max of 50x a second, but rendering runs full speed. I put in rotation for the sprites but that reduced my fps to <10 for 300 sprites, non alpha blended. You couldn’t see the rotation anyway with all those sprites, heh, its a real blizzard.
.
Still waiting for the guy who issued the challenge to come up with something…
???
nonnus: please read the board messager.
The snowflake demo ran at 51 FPS on my PC (2.2 Athlon with a nice video card that obviously doesn’t come into play very much with such a light program). The original demo came in at 92 FPS.
I guess my question is – what’s with all the griping? Seriously – what are you guys trying to create that requires you to blit more than 1000 or so images to the screen simultaneously? Obviously, you aren’t going to get as good frame rates as native code, but I’m sure at least some of you were programming games for more than the past 5 years or so, when it became common to throw hardware at poorly-designed code than, ahem, OPTIMIZE it, and design the code for the system you were programming on.
Java2D is an easy-to-use library that gets decent results. It’s not Direct3D, but, then again, Direct3D is a pain in the butt to program (not as horrible as it once was, but it still isn’t too much fun). Discussing problems with an API is good, but complaining about it ad nauseum really doesn’t help. Wait for 1.5, and see what they’ve added to it. If you think J2D sucks, there are other libraries out there… saying “see, it still sucks” really accomplishes nothing.
No, you are missing the point. The API is good, the implementation is poor. What’s the difference between throwing a 2.4GHz processor at a problem or a useless ancient TNT? A TNT is capable of twice this performance in hardware using D3D (or GL) - but the Sun implementation does not use high performance APIs underneath. I’m saying, it’s 2004, we’ve had the technology and the APIs in the real world to be able to achieve this reliably since the last millenium - why is the Java implementation still so slow?
(25-30fps with snowflakes. Yuk! And btw - I am running 1.5)
Cas
Sun’s current implementation ‘sucks’ to you? Then, why not using an other implementation?
There is the agile2D that uses gl4java . it is reported as a great boost when using alpha compositing, and a boost in general. there are others…
I guess than simply ranting is faster than testing an API and asking for debate about intelligent subjects, like ‘how to make sun integrate that other XXX pipeline as a default one’, or ‘what are the best alternate java2D implementations for gaming?’
Or, even better, starting a new thread like ’ why don’t we make a fast lightweight java gaming java2d library based on a GL pipeline that will please us’ and implementing one… this is something that could have been done… mmhhhh… three years ago, i think…
man, all that energy lost for nothing…
You’re missing the point, too
Here, I’m talking about the standard implementation, the one that ships, the one everyone’s stuck with, the API everyone knows. I’m talking about out-of-the-box, It Just Works. I’m talking about suddenly accelerating all those existing apps.
What I’m not talking about is using LWJGL or JOGL. I could whip up a sprite demo using LWJGL and shame every demo in here but that’s not the point of what I’m saying. I’m asking: why is Java 2D still so slow after nearly a decade?
Cas
[quote]Sun’s current implementation ‘sucks’ to you? Then, why not using an other implementation?
…
I guess than simply ranting is faster than testing an API and asking for debate about intelligent subjects, like ‘how to make sun integrate that other XXX pipeline as a default one’, or ‘what are the best alternate java2D implementations for gaming?’
…
Or, even better, starting a new thread like ’ why don’t we make a fast lightweight java gaming java2d library based on a GL pipeline that will please us’ and implementing one… this is something that could have been done… mmhhhh… three years ago, i think…
man, all that energy lost for nothing…
[/quote]
Um, you’re saying this in reply to Cas ? ???
I don’t use LWJGL (sorry, guys), but I know that not only is it done and working, but also how tirelessly (well, actually he may be tired at last ;)…) Cas has tried to get the GTG / J2D / etc groups @ sun to improve things, (according to his opinion of how they ought to be).
[quote]I’m asking: why is Java 2D still so slow after nearly a decade?
[/quote]
Why not simply starting the thread with that question?
Nevertheless, to stick to your thoughts, i think the right question should be:
“why is java2D still not fully hardware accelerated on parts that can actually be”
simply because:
I think that most of the answer is “because no one did it”, and also “because it’s not as simple as we might think”…
Then, let’s be constructive… i started a thread about 1.5 graphic acceleration and added a small contest… get there, participate/
edit
[quote]i started a thread about 1.5 graphic acceleration and added a small contest… get there, participate
[/quote]
Yeah, that’s what this thread was about, too Shall we stop this one or go to the other thread?
Cas
the thread might be interesting to continue if we try something.
let’s take one of the applications that were done here and convert it to Agile2D or any hardware accelerated java2D implementation. let’s see the results we have then, and see how it compares to actual java2d, then compare it to 1.5 java2d.
that might be useful in finding where are the things that needs to be improved, if still the GL pipeline (linux) and other accelerations (vram for win32) are too slow or bad.
Anyway, it will give us an idea of what we might get to when things get accelerated as we all expect them to be in a near future.
The following is from the Agile2D page:
[quote]Importantly, drawing generic shapes and text is sometimes slower under OpenGL. The issue with general shapes can be somewhat mitigated by using immutable shapes - Agile2D caches immutable shapes using OpenGL display lists and can render them significantly faster (on the order of 50,000 shapes per second using the same test conditions above).
[/quote]
My own real work (the stuff which pays) does a great deal of general shape drawing (mostly wide polylines), each of which is rendered once only. So while OpenGL may speed up many of the operations you want for games, Java2D needs to provide a good balance of performance for other uses as well. That makes the job of using hardware accelleration much harder — it can easily turn into hardware decelleration for another group. It is already the case that my code works faster when I turn anti-alliassing ON — because that stops any attempt to use the hardware and useless punting between system memory and video memory.
For complex high quality 2D rendering Java2D seems to work as well as anything available (and allegedly rather better than GDI+). So given that current hardware provides only limited support for 2D, perhaps it is better to leave Java2D as it is and use a specialist API for 3D/games work. Certainly use 3D acc. if possible without significantly compromising performance of code using features which can’t be accellerated, but don’t hold your breath waiting for dramatic improvements.
Ah - but I don’t want everything hyper accelerated!
There are a few key areas which are used by the vast number of apps out there which could be accelerated with GL or D3D:
[] Blitting
[] Rectangles & triangles
[*] Lines
Leave the other stuff using the normal pipeline.
Incidentally poly drawing in GL is not usually optimised in consumer cards. The underlying functionality is meant to be the same as Java2D more or less but because the consumer cards are largely optimised for games, they’ve never bothered too much with the performance.
Cas
Ick, well I’m glad I’m not using a Mac, how depressing. I get 60FPS solid on my crappy work machine (Win2k) without alpha. 30 solid with alpha. And the scrolling is smooth. Well just one more oddness about J2D, you can’t count on any two machines running the same code even close to the same way.
Off topic a bit but at 800x600 that’s only
a> 1 Screen clear
b> 475 non transparent blits of 32x32 images
c> 32 blits of 50% alpha channel of a 32x32 image
Is there a “big” different between the snowflakes that aren’t completely filled images and my block tile? In other words is it likely that a snow flake, having large portions of the image being completely transparent, would perform better?
Profile the code, I bet all my worldly possessions that the 32 alpha blits are taking more than 90% of the processing time per frame.
Read back from vram realy IS that slow.
The trouble, as we know, is that trying to guess which pipeline to use is tricky and swapping when you guess wrong is expensive.
i’ve discussed with nonnus, if he permits me to quote our private discussion, i’ll tell you how he did his sprite drawing and what conclusion we can draw from that.
we’ll be able to go further in that way