Ben Galbraith's Blog

October 2007 Archives

Java on Leopard: The New Rendering Pipeline

In my recent duo of "Whiners! No whining!" blog posts, I made a statement with which some commenters have taken issue:

the already-mentioned transition to Sun's rendering pipeline (a tough but correct decision reflecting a commitment to cross-platform fidelity)

Specifically, Michael Urban wrote in to say:

I really don't see how this has anything to do with cross-platform fidelity. After all, Sun JVMs don't even use the Sun pipeline by default anymore. They use the OpenGL pipeline where / when it is available. I think all Apple really did by switching to the Sun pipeline is make Java2D performance unusably slow, and create tons of support headaches for developers who now have to field all the complaints from their customers about why their application no long works correctly on Leopard, and either explain to the customer who to enable the Quartz pipeline, or ship a patch for their application to re-enable the Quartz pipeline.

Michael, as you'll see below, Sun's OpenGL renderer is indeed part of the pipeline Apple is now using. And unless I'm really out of date, I think the traditional GDI platform is still used on the majority of Windows JRE installs.

And "opinali" opined:

but what you said about the transition to the Sun rendering pipeline being an improvement, that was pure spin that I'd only parse as radical Mac zealotry. There is NO justification for this (except Apple having no resources / time / priority to update the accelerated pipeline for the new OS). It's the opposite direction that everybody else is moving; see for example Java 6 UpdateN, which will move to the new D3D-accelerated pipeline by default on Windows. The Java platform must keep up with the LAF improvements of the latest OSs, like Vista and OSX, which are severely raising the bar in sfx (remarkably with WPF, Quartz, Beryl etc) so the Java toolkits (AWT/Swing/J2D) can't reasonably compete without full acceleration. And also, Java must support the development of "filthy rich" clients, not that I like this trend, but many users do so developers should be able to crank out sophisticated J2D effects that don't bring Java's performance to its knees. These requirements are MUCH more important than "pixel-by-pixel portability" (and for this, there's always the option of the portable Java LAF).

Well, look. Dissent on this topic is perfectly reasonable; there are trade-offs at work. But, I'm confident that in the final analysis, most folks will agree this was the right decision.

Let's start with precedent. Initially, Sun relied on the underlying platforms to perform font rendering, but in Java 1.2 a new Java2D-based pipeline was introduced. This pipeline has represented a substantial engineering investment, especially as Adobe font support and subpixel anti-aliasing have come into the picture. Why not just use the underlying platform's font renderer?

The answer, of course, is that it would be nearly impossible to write cross-platform applications that do any detailed layout or typography work without Java itself handling the rendering. Sun abandoned the technically superior rendering approach in most situations in the name of compatibility.

Now, with Quartz, we see shades of the same issue. Quartz is great, Quartz makes certain drawing operations wicked fast in Java, but Quartz is much different than Sun's pipeline. The canonical example of just how different is the fact that aliased lines require Apple's adapter to draw an anti-aliased line (the *only* kind of line in Quartz) and then mask out the aliased pixels. Try some benchmarks to see just how slow this is.

Anyone who has written a rendering-heavy app has run into the pain that these differences cause. Any time the cross platform abstraction breaks and you need to adapt for the underlying platform, Java loses (or, phrased less dramatically, the value proposition of Java leaks in direct proportion to how often its abstractions leak).

Now that Sun has produced an OpenGL pipeline and is committed to making it work, why wouldn't Apple drop their own Java bridge to a Cocoa bridge to OpenGL in favor of Sun's OpenGL pipeline? Sun now pays the tax to make OpenGL behave the same as their traditional GDI (and Linux and Solaris equivalent) pipelines.

Thus, the Apple team no longer duplicates work that Sun is doing and they can spend more time on other features (like porting the new applet architecture to OS X, for example).

There are really only two sets of potential losers here: those who use Java to develop for OS X and don't care about other platforms, and those who need a fully tested and optimized Sun rendering pipeline today.

For the former, I'm convinced it's not a big deal. If you really want to take advantage of OS X goodies, learn Ruby and use the Ruby/Cocoa bridge. If you're content to just look like a native OS X app and don't need really fancy effects, the new Aqua look-and-feel is quite nice and I'm hopeful it will evolve favorably over time.

For the latter group--that need it today--I think you're confusing needs and wants. Use Quartz today and switch to the Sun pipeline when you're ready. In my own testing, it works quite well for most needs.

Am I wrong? Was this move a blunder? I'm curious to hear other points of view.

UPDATE: amasson pointed out that the Quartz stack includes a non-retained mode drawing API. I excised the relevant paragraph. See comments below for details. Thanks amasson!

More on Leopard's Java 1.5: The Release Notes Michael Urban Should Have Read

I recently blogged about the recent Mac whining from the Java community. Subsequently, I browsed through OS X 10.5 Leopard's Java release notes. Wow!

I think most people have by now realized that Michael Urban's straw-that-broke-the-camel's-back example of how Apple has regressed Java 5 is actually a step forward (i.e., the Aqua look-and-feel uses the *right* icon in message boxes now), but it gets much better.

Some of my favorites include:

• "It is now possible to create a circular indeterminate progress indicator from a JProgressBar in Swing. Setting the "JProgressBar.style" client property to "circular" will create a small round indicator when the progress bar has been setIndeterminate(true). Please see tech note TN2196 "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information."
• "Horizontal scroll events are now delivered to JScrollPanes as Shift+ScrollWheel events, since there is no horizontal scrolling API in Java. Horizontal scrolling mouse events will now move the content view horizontally, along with Shift key modifier events."
• "There has been no way to specify smaller versions of the default Mac OS X Aqua controls. Many JComponents now change their default size, appearance, and font when the "JComponent.sizeVariant" client property is set to "small" or "mini". Please see the tech note "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information."
• "JTextFields can now be converted into search files using the "TextField.variant" client property set to "search". Please see the tech note "New Control Styles available within J2SE 5.0 on Mac OS X 10.5" for more information and additional options to configure JTextField based search fields."
• Apple introduced a 64-bit JVM with Leopard along-side the 32-bit JVM.

And, as anyone who has spent any time playing with the JRE will have noticed, the release notes omit many smaller features related to polish in their ground-up rewrite of the Aqua look-and-feel.

There will always be the whiners about Java 1.next; Apple is Apple. As the snake says in the proverbial parable, "you knew what [Apple] was when you [bought your MacBook Pro]." Whine about this to someone who cares.

But those who complain that Apple has lessened their support for Java at a time when Apple has done more to make Java a first-class peer of Cocoa and other dev environments--you could not be more misinformed.

UPDATE: I posted follow-up comments on the new rendering pipeline in a new blog entry.

The (Java on OS X) Sky is Falling!

With a tip of the hat to Casablanca, I'm shocked--SHOCKED--to read the really rather embarrassing blog entries from folks in the community about the state of Java in Apple's latest OS release (see David Herron's blog for a round up of some).

Please.

It turns out that Swing in Leopard represents a huge leap forward in Apple's commitment to desktop Java. Among the new goodies I've stumbled across are animated triangles in JTrees, the already-mentioned transition to Sun's rendering pipeline (a tough but correct decision reflecting a commitment to cross-platform fidelity), a revised UI for JTabbedPane, improved button rendering behavior, and more.

I suspect as time passes, more improvements will come out and folks will understand just how busy the Apple Java team has been.

So, what, there are some bugs in OS X 10.5.0? They didn't have 1.6 ready out-of-the-chutes? Big deal. Give it time, just like we have with every release of Java since OS X first shipped with Java 1.3. Only now, thanks to Parallels/Fusion, we actually have a great alternative for the impatient.

Kudos, Apple, for a fine release and for all your hard work.

UPDATE: I've elaborated a bit after reading the release notes.

This work is licensed under a Creative Commons License.