And so it begins :)

[Mike Swingler]

On Jan 11, 2011, at 9:58 AM, Rob Ross wrote:

> Woo hoo. Happy to see this day finally arrive.
> 
> So, first, a question: What is "TOT", as in "Needs refresh from Apple TOT"?
> 
> http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status

As Lœfty mentioned, TOT is Top Of Tree, which is what we currently build Java SE 6 from.

> Next, on the Aqua LaF, I'd like to suggest that it behave like any "regular" Swing LaF, where drawing is done via Java2D APIs, and not calling back into the native environment to use heavyweight peers for drawing and event handling. Sure, it's more work in the short term, but I think it has many advantages.

Our current plan is to actually use a hybrid approach: use the native Aqua drawing routines to blit onto BufferedImages, and then use pure Java2D drawing to 9-slice those images and stretch-paint them onto the Java drawing surface (which will be OpenGL-based).

> First, it avoids calling native methods via JNI (at the low level it's all JNI), which makes rendering faster. Aqua is a pretty LaF for Java, but it's also the slowest rendering LaF in popular use. ( I've heard this from the Swing & Java2D team at the last 3 JavaOne conferences, so if anyone wants to start a flame fest on this point, please email them.)
> 
> Second, it allows for customization in drawing that works for every other LaF except Aqua or SWT. Things you can do in Metal/Ocean/Windows LaFs and others sometimes just don't work in Aqua. For example, I have many printing issues when trying to use customized drawing, where printing works fine on other platforms but not on Aqua.

This is because Aqua drawing had drills down to the window back-buffer in Java SE 6. We will not be taking that approach in OpenJDK 7, because the OpenGL rendering context is simply incompatible with this approach.

> Third, having all the drawing code rendered on the Java side means it's easier to tweak that code to have a high fidelity with the native Cocoa look & feel. This may sound counter-intutive at first, but if this weren't the case there would be no need of frameworks like Quaqua or  MacWidgets which exist to "fix" problems in the "native" Aqua implementation, so the Java UI more closely resembles the native Cocoa UI.

This issue is negated with a open source implementation of the Aqua LaF. Also keep in mind that Mac OS X itself changes appearance from release to release, and that those changes will be picked up for free by using the native drawing routines. Also, there is a big uncanny valley between being "close" and being "the same". It's bad enough that default Swing behaviors get in the way of implementing Aqua behaviors, all of which have to be re-implemented in the LaF.

> Fourth, having all the UI code on the Java side makes it easer to enhance, change, and add new UI features to the LaF and doesn't require writing JNI code to access that new functionality on the native Cocoa side. A UI delegate implementation in pure Java also doesn't have to worry about the particular version of Mac OS X; so if new FooUI is introduced into Swing, we don't have to rely on native platform details to render it, we just draw and manage events on the Java side. This works better for portability as well.

You will not have to worry about using JNI at all to use the Aqua drawing routines in OpenJDK 7. There is a pure Java interface that bridges to these routines already exposed in the JavaRuntimeSupport.framework that the existing Java SE 6 implementation is using today.

> There are probably other good reasons as well, e.g. "All the other LaFs do it this way", although that in itself is not the best reason. But consistency is a worthy goal.
> 
> Thoughts?

Regards,
Mike Swingler
Java Engineering
Apple Inc.