Just something to be aware of if you are not using JOGL or LWGL and hope to run well on a Mac. This is why it is critical on the Mac platform to use an image format that is supported by the native APIs (e.g. a ‘compatible’ image).
The good news I see in the above is that it looks like the OpenGL pipeline planned for unix will be implemented on the Mac. Hopefully Apple won’t lag too far behind with their 1.5 release.
IMO The even better news is that Apple is considering performance problems bugs. Thats pretty open minded of them 
True. While things may not happen as fast as I would like, I have to say that I’m generally impressed with the Apple folks and their Java efforts. I guess if you are going to claim to produce the fastest personal computer in the world that you better consider performance an issue though 
More good stuff to know about optimal graphics on Macs…
[quote] From: gziemski at apple.com
Subject: LazyDrawing and LazyPixelConversion description
Date: December 24, 2003 2:02:07 PM EST
Cc: java-dev at lists.apple.com
Craig,
Type “java apple.awt.RuntimeOptions” to get a brief description of all
available runtime options.
LazyDrawing (apple.awt.graphics.EnableLazyDrawing) uses a queue to
collect similar graphics primitives (same stroke, transformation,
etc…) before flushing them to surface. This benefits applications that
draw a lot of similar primitives. You can try increasing the size of
the queue (apple.awt.graphics.EnableLazyDrawingQueueSize) if you can
spare memory, but want more speed. This optimization is turned ON by
default.
LazyPixelConversion minimizes the amount of pixel conversions required
when handling those Java image types that can not be handled natively
by CoreGraphics. There are only a few BufferedImages that CoreGraphics
can handle without pixel conversion, ie: TYPE_INT_ARGB_PRE,
TYPE_INT_RGB , TYPE_USHORT_555_RGB and TYPE_BYTE_GRAY. Notice that even
TYPE_INT_ARGB is not supported natively (as destination) - we need to
manually alpha premultiple color bands in this case. If you construct a
BufferedImage by passing your own DataBuffer, or you access the image
data buffer later, we have to turn this optimization off for that
image. It was mostly implemented to boost the performance of all those
apps coming from other platforms, where the image types are hardcoded.
Use createCompatibleImage to create BufferedImages that are guaranteed
to be natively supported on all platforms. This optimization is turned
ON by default.
cheers
[/quote]
Hey!
Tell him we’ll make him his own Mac Graphics topic on JGO if he’d come answer questions and give advice
JK
dont give him even more to do Jeff! let our Gerard get on with it hes a top dude- top top dude…
[quote]Hey!
Tell him we’ll make him his own Mac Graphics topic on JGO if he’d come answer questions and give advice
JK
[/quote]
+1
Basically, I’m never going to subscribe to a Mac-specific list (too many subs already!), but…I’d definitely read the forum if it were on JGO (because I can skim-read topics I’m not directly working on but which it helps to know what the current state-of-play is).
I’m sure there are many more like me :).
If you look back you’ll see that there are a LOT of compatibility problems with games not running OK on Mac’s. My guesstimate is about 5-10 times as many as don’t run on linux (usually they don’t run because the author only has windows and hard-coded something like “C:\WINDOWS” or made a windows-only JNLP :)).
These are programmer mistakes/bugs, not problems with Java’s WORA, and it would help educate java developers if we had a Mac-OS-X category.
Actually…