wow … first I did was to switch on -Dsun.java2d.opengl=true
That REALLY had a HUGE effect! My apps became that INCREDIBLY slow! 
One thing worth mentioning… the SDK is called JDK again ;D
But I’m wondering if that was really intentionally (well I like “JDK” more ;)).
The Tiger release looks nice. Have to do some tests, though. 
However, I’ve first to get used to the standard Ocean L&F. Looks very … blue. The old one has gone? Couldn’t use it with JEdit or any other Java app.
Also, some letters of the font for the Windows L&F for all Java apps are ugly, at least on my Win2000 box. Anybody noticed this, too?
Look at this injured “8” and the cockeyed “M”.
as well as
PS: How do you make your old JBuilderX to compile Java 1.5 ? I’ve changed the project’s JDK but it always appends some “source -1.4” to the JDK compiler and then of course it won’t work…
I moaned about the ugly un-antialiased crapcake fonts in Webstart a few months ago Bah.
Does anyone know how to specify global system properties for the JRE?
Cas
[quote]I moaned about the ugly un-antialiased crapcake fonts in Webstart a few months ago Bah.
[/quote]
Oh, it’s not only Webstart, it’s any Java app using the Windows Look-and-Feel of the new Java 1.5.
Or is it just my system?
[quote]Does anyone know how to specify global system properties for the JRE?
[/quote]
Unfortunately no.
I use the workaround to alter Windows’ open-action for “.jar” files, by changing it to something like
java -Dswing.plaf.metal.controlFont=Dialog-plain-12 -jar “%1” %*
to avoid this fat non-aliased font of the standard Ocean L&F to something more subtle.
Fonts seem to be bad an many systems, mine as well.
Thanks for your observation. So it’s probably the font style for the Windows L&F.
I’ve to confess I hardly use it anyway (except the Java console on Win uses it automatically). I like the standard Metal L&F best - and it still looks very nice.
All my important Java applications (and my small Jogl and Xith game project) work on the new Tiger Java without any problems so far. Which is great! Also some apps start a lot of faster due to Class Data Sharing.
So I’d like to say a big thank you Sun and all laboriously engineers at Sun for this fine release !
Hopefully Java reaches the masses and comes to the point it really deserves. Such a beautiful runtime plus language.
I wrote up a quick ‘performance’ tester to mess with the openGL pipeline settings stuff.
It gives performance on opaque, transparent, and translucent images.
If anyone would like it, let me know and I’ll post it to a website for you to grab.
Regards,
Dr. A>
Yes please. Do that.
@home, the opengl pipeline is not only slow, but even refuses to show anything when used with NetBeans.
Quite disappointing to so far…
It’ll be tonight, but I’ll post it and then update here.
Regards,
Dr. A>
Here ya go -
To use it -
java ImageSpeedTest
You’ll get the results on the command line. You can also pass in the size of the textures you want generated -
java ImageSpeedTest 128 128
Check the code for the other options such as screen size and bit depth.
Here are some results from my work computer -
C:\javadev\eclipse 2.1\workspace\tests>java ImageSpeedTest
Display mode: 800x600 at 32bits
Texture size: 65x65
Opaque: 55802.668 images/sec
Transparent: 61013.332 images/sec
Translucent: 3429.3333 images/sec
C:\javadev\eclipse 2.1\workspace\tests>java -Dsun.java2d.opengl=True ImageSpeedTest 65 65
Display mode: 800x600 at 32bits
Texture size: 65x65
OpenGL pipeline enabled for default config on screen 0
Opaque: 46876.0 images/sec
Transparent: 35142.0 images/sec
Translucent: 32492.666 images/sec
C:\javadev\eclipse 2.1\workspace\tests>java -Dsun.java2d.opengl=True ImageSpeedTest 64 64
Display mode: 800x600 at 32bits
Texture size: 64x64
OpenGL pipeline enabled for default config on screen 0
Opaque: 49197.332 images/sec
Transparent: 36456.0 images/sec
Translucent: 34026.0 images/sec
C:\javadev\eclipse 2.1\workspace\tests>java -Dsun.java2d.opengl=True ImageSpeedTest 64 65
Display mode: 800x600 at 32bits
Texture size: 64x65
OpenGL pipeline enabled for default config on screen 0
Opaque: 48704.0 images/sec
Transparent: 36293.332 images/sec
Translucent: 33652.0 images/sec
Its interesting how the Translucent gains so much, while the other two types are lower than the non openGL’d version. Hmmmm…
Dr. A>
PS - This code is reworked from Brackeen’s recent book, so I don’t get too much credit for it.
PPS - The image icon being drawn with using openGL is BEYOND slow, you can actually see it draw line by line on the screen.
approx. same results here.
Translucent grows so much faster bc. transluency is extremely hard to do in software. But why does opaque/transparent perform so bad?
The most significant effect here is that the one-time call
g.drawImage(bgImage, 0, 0, null);
here takes >1s with opengl enabled. Without opengl, the time is not noticable. I think that might be the reason why my apps perform THAT bad (its not just a slight slowdown, its near to unusable).
It also seems that small images are not good for OGL. If you increase texture size to e.g. 512, the results change:
C:\development\Java test> java ImageSpeedTest 512 512
Display mode: 800x600 at 32bits
Texture size: 512x512
Opaque: 1577.441 images/sec
Transparent: 81.279144 images/sec
Translucent: 55.29647 images/sec
C:\development\Java test> java -Dsun.java2d.opengl=True ImageSpeedTest 512 512
Display mode: 800x600 at 32bits
Texture size: 512x512
OpenGL pipeline enabled for default config on screen 0
Opaque: 1888.7408 images/sec
Transparent: 1819.3334 images/sec
Translucent: 1867.3334 images/sec
It also seems that small images are not good for OGL
Something like that… bigger images are bad for direct draw (everything with more than 65536 pixels [256*256])
All those problems (weird fonts and unusable OGL pipeline) are known to exist since first alpha. Like, for almost a year. Sad. It gets even worse with new Sun’s release plan. http://weblogs.java.net/blog/mreinhold/archive/2004/09/tigers_and_must.html
Seems we will loose dot-dot releases, and will have to wait 18-24 months for new features and bigger advances, with only small critical bugfix releases every 2-3 months (like _xx thingy today). I don’t find that attractive at all considering current state of J2SE desktop stack.
[quote]It gets even worse with new Sun’s release plan. http://weblogs.java.net/blog/mreinhold/archive/2004/09/tigers_and_must.html
Seems we will loose dot-dot releases, and will have to wait 18-24 months for new features and bigger advances, with only small critical bugfix releases every 2-3 months (like _xx thingy today). I don’t find that attractive at all considering current state of J2SE desktop stack.
[/quote]
The blog doesn’t need to mean a negative thing. Any company has to concentrate on the important things. In particular in hard times for Sun (naturally opinions diverge on what is important
We’ll get feature releases more oftenly which is a good thing. Since the Java clone Dotnet is so similar to Java, the original has to move, too, in order to stay the original. 
java ImageSpeedTest
Display mode: 800x600 at 32bits
Texture size: 65x65
Opaque: 34063.332 images/sec
Transparent: 37195.332 images/sec
Translucent: 1176.0 images/sec
Trying opengl blah = True didn’t output anything and didn’t have any visual effect except at one point I saw some silhouettes of my other windows bleed through.
If y’all just stick to using the bare bones of Java and use the LWJGL to code your games you won’t have a problem
Cas
Is there a way to enable that setting from within the app?
Can you change a setting on the fly? It might be interesting to try and turn it on in the app, do some drawing, then turn it off and draw some more.
My idea is, what if you could have the pipeline off for opaque and transparent blits, then enable it for your translucent ones?
Ideas?
Dr. A>