Skip to main content

Java on Leopard: The New Rendering Pipeline

Posted by javaben on October 31, 2007 at 9:44 AM PDT

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!

Related Topics >>