I couldn't get the jar file to be executable, played with the manifest a couple of ways but no go. Don't think I can do webstart from geocities, really don't want to try.

This is really odd; running from the jar its 10 fps slower on my comp; max fps is about 30. There's no timing, it runs flat out. 800x600 windowed using BufferedImage (its not even a compatible BufferedImage, I had to have int rgb to do the blending )and BufferStrategy - probably some wasted effort there. I've only tried it on windows, although there is nothing esoteric about the code.

works at 70-75fps on a p4 2.2ghz/radeon9000 on XP jre1.5.0beta1.55fps under linux, same jre, same machine. unfortunatly, the opengl flag did not change anything.. (note to self... will have to rant about that) Saw some flashes, there.

Not fullscreen, but has nothing to do for the test and the jar is runnable.I see this post as related to Cas's rant about awt, thus fullscreen is there imho to help plugging LWJGL, and not to be related to any perf improvement. Let's take fullscreen out of that...

Well, there was a chance I was wrong and I wanted to be shown how to do it But it looks like I might be right in thinking that it's not going to get any faster until someone rips out the DDraw code in Windows and replaces it with modern D3D code.

In the meantime I might continue with Lunar Lander and use bitmask transparency instead.

mhhh.anyway, i'd be curious to see the GL pipeline working. if it does as correctly as it should this thread and all hidden meanings will be pointless.

About java2D. i don't agree it is crap. java2d is a wonderfully designed 2d API. It's just too slow for some of you.. (while by the way is not really what i thought when i tried the jar nonnus posted)Anyway, it's still the problematic of the right tool for the right job.By the way, there is a gl implementation of java2D that you might plug in. anyone tried it?http://www.cs.umd.edu/hcil/agile2d/

IMO What we *realy* *realy* need (after the D3D acceleration has been fully implemented) is some kind of way to query the capabilities of a given GraphicsDevice.

1

graphicsDevice.isAccelerated(operation, source, destination);

If a required part of the pipeline isn't hardware accelerated (a particuler AlphaComposite/AffineTransform op for instance), we can detect it, and either use a different op (precalc. rotations, bitmask instead of full alpha etc), or fall back entirely to software rendering.

Ah, now, there's been many a heated debate on this in the OpenGL world. You have noticed that OpenGL does not give you any caps bits to say what is and isn't HW accelerated - and with good reason; it makes programming a total nightmare. GL only advertises capability, not performance.

I'd like Java2D to work like this. After all, it's meant to be easy to program, like GL. What's obvious here is that what Java2D is being used for is being seriously affected by its performance. You can't go writing tons of different renderers for all different permutations of hardware acceleration or you'd just lose all the advantage of an abstract toolkit in the first place, so you instead have to rely on the underlying technology to run the capabilities it has at the maximum performance achievable on common hardware. This means D3D on Windows. Or even OpenGL. I'd prefer GL, even on Windows.

So when I ask for 32 bit RGBA sprites, I get them no matter what; and most of the time they will be in a hardware accelerated pipeline because most computers have hardware accelerated 3D accelerators these days. But if not, then at least it could fall back to software. This is very similar to how GL is implemented. Successfully, I might add.

However, J2D doesn't seem to have decided which path they want to follow.Consequently, we have an API that offers some performance querying functionality, but not enough for it to be of any use (+ive or -ive :/)

At the moment, new BufferedImage(.....) will get you an image stored in main memory only; (unmanaged)graphicsConfiguration.createCompatibleImage(....) on the other hand will get you a BufferedImage stored in main memory, and eligable for caching in vram. (managed)

But, once created, there is no way(accessable to a user of the API) to distinguish between a managed and unmanaged image.The 2 can behave very differently(from a performance perspective), under many circumstances.

Under 1.5, all images will be placed in accelerated memory if possible. But unfortunately it's the "if possible" bit that's the sticking point; as soon as you're using alpha channels, it's no longer possible (by default, at any rate). Bah.

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.

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).

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....

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?

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?

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