Skip to main content

Effectuation: The Intro

Posted by campbell on February 1, 2008 at 2:32 AM PST

For the past few months, I've been involved with various aspects of Project Scene Graph and the JavaFX Script runtime libraries. Hans has already introduced the core elements of the scenegraph package, and Chet has donned his Groucho mask to explain the animation package in great detail (three chairs for that!).

Today I'm finally going to talk about the third major component of the overall Scene Graph project, and that is the Effects Framework. If you've been wondering why I've been quiet lately, this is the reason.

Our team has already had plenty of experience in delivering GPU-accelerated imaging operations. Now we've taken it to the next level, by offering a long list of effects commonly used by designers, packaging them up into an easy-to-use API, and providing a sophisticated implementation that can take advantage of GPU acceleration (and later, SIMD instructions on the CPU) for blazingly fast performance.

All of this integrates seamlessly with the scenegraph and animation packages, and soon will be exposed just as pleasantly through the JavaFX Script runtime APIs. You can even take advantage of the Effects Framework in existing Swing and Java 2D applications.

Anyway, enough yapping; let's move on to the introductory demo... This application demonstrates just a few of the effects available in the new API. I'll let it speak for itself. (Requires Java SE 6 or above.)




With default options -- will take advantage of the
Direct3D-based backend (if possible*) on Windows...



With OpenGL backend enabled -- for Windows, Linux, and Solaris (if possible*);
Mac OS X coming soon...



With all GPU-acceleration disabled -- try this if you have problems with
one of the above.

(*) GPU acceleration requires the latest build of
JDK 6uN, a
compatible graphics card, and up-to-date graphics drivers. If
GPU acceleration cannot be enabled for any reason, the framework
will automatically fall back on the software-based implementation.
Yes, the software-based backend is much slower than it should be;
we're working on that.

These projects are still in the early stages, but over the next few weeks, I'll have much more to say about (and more demos to share from) the Effects Framework and the Scene Graph project at large, so stay tuned. In the meantime, take a gander at the JavaDocs and let us know what you think. Hans should have news shortly of an 0.5 release that includes all of this and more.

In my ears: Enon, "High Society"

In my eyes: Found Magazine #3

Related Topics >>


@xcolwell: The AWT forum could provide more details, but heavyweight/lightweight mixing should be improved in an upcoming JDK 6 update release. This means better support for heavyweight components embedded in lightweight, but not necessarily the other way around (heavyweight rendering typically blows through to the screen, so we can't render on top).

hi Chris, sorry this is off topic a bit, but I'm wondering whether heavyweight and lightweight components are closer to playing nice together. E.g. will a lightweight component ever be able to render over a heavyweight component? I remember hearing this was on the horizon a year ago ... thanks!

Unfortunately all of OGL-pipeline related demos result in black artefacts (Geforce8800GTS, Windows XP, Update N b12) . From time to time I can see new rendered regions with text. I have the same problems with all the jogl-demos which utilize the OGL-pipeline. At first it seemed to be a driver bug. My system crashed when I tried the pipeline using the first drivers I got for my card. The crashes gone away but the artefacts came. Maybe it's something with cleaning up the FBO that's going wrong on the newer Geforce series.

@pbannister: These effects use close to 0% CPU when the GPU-accelerated backends are in use, which will be the case for a majority of end users' machines by the time JDK 6u10 ships in a few months. As for the remaining machines where the GPU is not a viable option... Since this blog was posted, performance of the CPU-based backend has improved considerably thanks to an optimized native backend, which is significantly faster than the unoptimized pure Java backend (50% faster, and that's just the beginning).

OMG! it's animation! Again (and again and ... and again ...).

The effects are nice, but the CPU is running near-flat-out (on my adequate but not a gaming machine laptop), and the result is occasionally jittery. As "Q" said to 007: "never let them see you bleed". Applications with special effects that shudder badly when they cannot get a firehose worth of CPU are going to look lousy. You never want your applications to look lousy.

Every few years new developers fall in love with the latest special effect that looks "kewl" in demos but prove tedious in repeated use. Seems this cycle has repeated every few years since (at least) the late 1980's.

I am all for adding interesting and useful visual effects to GUI applications, but the end effect has to be seamless, even when the box we are running on is not the fastest, and even when the box is busy doing other things. Otherwise the user experience is ugly.

It is a natural thing for developers to consider their application the most important thing running on the box, but users do not see things the same way. You have to be a good citizen in the little community of code running on the end user's box, and CPU-sucking special effects are ... at least dubious.

ok, it turns out I'm an idiot. The old direct X stuff I was using (sun.java2d.ddscale=true) did anti-aliasing without asking, setting the hint on the graphics2d helped a lot with the new code ;-) So one question; assuming I was to want to do some automated timings to pick between a few different copy up methodologies, can I rely on stuff being synchronous, or is there something I can do to force a flush?

oops; ok i did find some documentation on debug options; this is what I'm seeing with the new JDK 6 sun.java2d.d3d.D3DSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, "D3D Surface") sun.java2d.d3d.D3DRTTSurfaceToSurfaceScale::ScaledBlit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface") vs previous versions on vista sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb) sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb) So at least I seem to be using Direct3D; is there a way to turn on anti-aliasing for this blit, and/or how do I turn on JOGL instead of D3D

Not strictly related to this post, but javagaming refuses to let me sign in up, so I thought I'd try here. I've been trying to get my Java Playstation emulator to play nicely with Vista. Basically I need to do a copy-up from a portion of emulated VRAM (basically an int[] I keep in a sensible Java2d format (RGB)) to the display. This needs to be a stretched blit based on the h/v scan rate of the TV mode. In the past I had used an int[] backed BufferedImage in main RAM (since I need to write to it a lot), and then the copy up would do an unstretched blit of the displayed portion of the VRAM to a VolatileImage, and a DirectX accelerated stretch blit to the display from the VolatileImage (this seemed to be the fastest way,and gives you the nice anti-aliasing you need given PSX's strange display modes). Vista obviously screwed stuff up with the disabling of the DirectX acceleration. I had been looking at using JOGL/Direct3d to do the streched blit, but it seems like stuff might be fixed again in this new release of Java 6, plus also I can't seem to tell what of that stuff is broken by Aero anyways I ran the attached demo and saw Direct3D backend usage, however my emu doesn't appear to be using DirectX (at least the stretch blit is not anti-aliased and doesn't seem particularly fast). I've been scouring the web, but can't seem to find the exact latest status on where Vista support lies. I'd happily plug in a JOGL based blit if that should be fast, but first I'd like to check I have the right system properties enabled, and/or debug what Java2d is doing. Obviously in the long run, I should add a JOGL based GPU anyway (rather than Java software rendered, but that surprisingly isn't as much of a bottleneck as the screen blit)

It doesn't use my GPU here on Linux Ubuntu 8.04.1, although all the proprietary drivers are installed and anything else in my system is able to use the GPU. I hope Sun will not keep Linux out with a CPU-only solution. I got GeForce 7600GT 256MB. Java update 10 build 27.

someone should please put the data to an other server and update the links of the project page. The effects framework is currently on the frontpage. the first impression works just once ;)

They're still having issues with's content, unfortunately =(

Unfortunately with 6uNb11 with D3D, I see no images at all. Just the text and big solid color squares. Normal apps seem to work just fine.

I can see it all with the non-GPU version though, and the blend modes work fast enough to play smoothly. We can always count on you for the coolest demos chris. How did you get 3D text and lighting effects without D3D or OGL!

I'm interested in how I might use these effects with Java2D though, without the scene graph. I hope to see Composite/BufferedImageOp classes for these.

oh god
* now i need a fresh set of underwear *

w00t ! That's very, very cool. Do you have any plan to expose the SiMD stuff to Java developpers too ? A SIMD framework with aligned data structure, the common operators, ect, would be very cool to have in Java.

This is why web start is really cool. I got the demo while it was up and even though the link seems to be broken I can still show it to people. I know I would have had to jump through some hoops to load an applet once the original site went down.

martin_dk: is apparently down right now.

All demos fails with: Unable to load resource:

And when were you planning on telling us about JSL?!? That's the most exciting part of this project! JSL appears to let us write our own effects and have them run on the graphics card. Can you give us any more information on it?

@benloud As far as i can tell, this seems self-contained and does not depend on scenegraph and animation at all. I guess that's chris meant by seamlessly.

I had to fiddle a bit to integrate it with a scenegraph scene, but it really is simple, create an SGEffect, and setEffect one of the effects in the library, setChild one SGNode.

(Severely blurring some swing components in real time allowed me to experience how one of my friends 'sees' without his glasses, thanks for that Chris :)

Ah, benloud, do you have a multiscreen system? If so, currently d3d accelelrated effects will only work on the primary screen. To be fixed soon.


Duh. ... utilization is less than 5% during the demo. Dmitri

benloud, could you please set env. variable J2D_TRACE_LEVEL=4 and run any swing app from the console and post the output (or send to me: tdv at sun dot com)?

On my system with Nvidia 7800 it runs fine with the d3d pipeline. CPU
utilization is <5% during the demo..

Java2D Team

@keeskuip: When the blend mode scene starts up, look in the lower left corner of the window. It should say "Using {CPU/OpenGL/Direct3D} backend"; if it's pegging your CPU, I'm guessing it's not able to use one of the GPU backends.

Would be nice if you say somewhere if you fell back on the software-based implementation. My cpu is 100% but I don't know if the hardware- or software-based implementation is on.