Works for me...

(Disclaimer: JavaFX enthusiast writing here.) The GeoView works pretty well here. I don't notice scrolling or any other issues with this or other Java/JavaFX applets. Notice that you really need JRE 6u18, and also JavaFX 1.2.3 - this point-release was readied especially to fix a few bugs for the GeoView app, days before the games started. (Unfortunately the JNLP doesn't enforce these runtime versions, it just requires JRE 5+ and JavaFX 1.2+, so the GeoView may run on older crap if you've already got it installed.) And you really need Windows - the JavaFX ports for Mac and Linux are still lagging a bit. On the Mac, the problem is Apple's JDK lag behind Sun's; on Linux the problem is much more severe as Linux's core media stack is a pile of monkey dung, from graphics drivers to the multiple crappy/nonintegrated sound subsystems etc.

The very first time you load the GeoView (or any FX app that's your first FX apps), there is a bigger download time because the JavaFX runtime weighs in ~10Mb, and that's assuming you've already got the latest JRE. But the warm-start is pretty good in my tests (JRE 6u18 is important for that, contains some significant improvs in the Java PlugIn cache where applets are stored).

Notice that GeoView will query its server for specific info, like each country's flag and medals, on demand as you navigate stuff. This data is stored in the Java PlugIn cache (check the JPG and JSON resources) so the next uses will be fast. Perhaps they could pre-load things in the background when the applet is idle, e.g. prefetching data from nodes that are "neighbor" to the node in focus, that would provide an even better perf. Don't blame the platform for everything; app design plays a big role in PERCEIVED performance.

Now, Flash is certainly ahead in deployment, but... I've just seen the Tour De Flex demo... pretty UN-impressive. The deployment is still good, but not brilliant: I already have the latest Flash so the initial UI loads reasonably quick (>5s) and without fuss. But it's certainly not in the "instantaneous" standard of most Flash applets; and I'm just talking the initial screen! Every single menu item I open for specific demos has a VERY noticeable, extra loading time - always several seconds, like the COLD-start of an entire small Java applet. The performance sucks horribly - drawing of the chrome, simple effects like fade when a modal dialog is shown, etc. Try dragging a window with transparency, e.g. in the TileWindow demo, the shitty performance JUMPS in your face. And don't tell me that Flash 10.1 will fix this with GPU acceleration and other enhancements - I AM already using 10.1beta2. (Doing this test on a Q6600 + NVidia Quadro FX1700, it's not a bleeding-edge gamer system but it's pretty decent. God helps Flex on a laptop with some Intel IGP.) The look&feel is nothing to be proud of, nor is the memory usage (a bit HIGHER than JavaFX's GeoView, in my tests).

All in all, for tiny applets there's still no competition to Flash which can cold-start a small SWF in a couple hundreds of milliseconds. But it's a different ball game for Flex/AIR, that demand very large frameworks that are downloaded on demand (and apparently without any decent caching). Flex/AIR is just as much slow-booting and RAM-eating as Java/JavaFX, so the playing field is much more level here (of course Adobe is still ahead in items like tooling, developer midshare, and runtime distribution - but then, they've been 10+ years in this game, so there's still a lot of ground for JavaFX and also Silverlight to catch up).

Wake Up and Smell The Coffee

Please understand what a scene graph is first? A scene graph is a data structure of descriptive object nodes that in themselves represent abstract graphics declaratively that are rendered through runtime (software and/or hardware pipeline) to produce graphic primitives on the target display device.

JavaFX is designed to support a scene graph

JavaFX is a Domain Specific Language

Swing was not designed to support a scenegraph runtime. It uses ``immediate mode graphics'' with GraphicsContext (AWT and Java 2D) as it underlying technology. Immediate mode graphics programming has been around since the 1980's with Windows Handles, X Windows Contexts, Borland Graphic Unit Contexts and of course Java AWT Graphics2D context.

Swing was designed to be an emulation of windows user interface technology of the period, the classic WIMP model (Windows Input Mouse and Pointer).

Smell the real coffee with the new kinds of UI/UX that you already know about to hit the streets. The Apple iPad is foregoing the traditional UI/UX of WIMP. It is a new style of consumer device with a touchscreen. Surely you do not think that Swing 2.0 will be able to execute on these devices or other slates (that you might be using in the five years). If you do then you are a dumb .....

With devices like Apple iPhone / Google Nexus you all know about the graphics objects that seemlessly rotate, scale, translate and shear; and can perspectively rotate. How on earth do they do that? You might have wondered in your mind. I hope you probably know that there is a programming model and graphics pipeline that makes what you see on iPhoneOS a doddle to program. It would be very hard and difficult to take a Swing UI 2.0 and develop it now to the iPad (or another other forthcoming competiting i-slate). This is why JavaFX was invented, or rather Christopher Oliver of See Beyond, created an experiment called Form-Follows-Function (F3) that in prototypical terms set the stall out for JavaFX. His research endeavours to build a language to manipulate a scene graph , see his blog on the older blog.sun.com, pre-date the announcement of the first generation Apple iPhone in January 2007 WWDC. Plus we all know that Chris Oliver and Apple were separated by concerns and could not be influenced by each other, in anyway.

Simply put, the new UI/UX mode is to have a runtime that supports a combined 2D/3D scenegraph runtime, which is performant and takes advantage of 3D graphics GPUs. If Tony Blair mentioned once: education, education, education and Bill Clinton mentioned once, the economy, economy, economy then please believe me, with JavaFX, and this including another graphics RIA solution, it is all about now the performance, performance, performance. Why? Because Apple are setting the agenda in this game. They just did in 2010 with the new Fangled Apple iPad. The demos were stunning when I had a change to watch them as podcast on iTunes. Flex, Silverlight and even JavaFX had better catch up.

I realise there are wide spread confusions here are that people think that JavaFX can only run inside a browser, or it is based on extension of Swing, or about a fluffy stackitecture and the runtime. The real prize to be able write RIA that can ported/target to a multiple of devices (screen) in one DSL and one runtime. This is the rocket science that everyone has to understand.

We are waiting for Oracle to finish the work that Chris Oliver started. Produce a Java/JavaFX runtime that supports scenegraphs and replaces the old fashion Abstract Windowing Toolkit (pipeline circa 1995) and then it will contain combined 2D and 3D graphics. This runtime is called tentatively by Oracle, "The PRISM Runtime" and it will solve not only JavaFX but also Java Runtime Environment (JRE). That's right even those m****f***rs of b**k*rs will be able to download the JRE with the Prism ``Stackitecture''. If they want they still run little bitty Java Plug-in based financial trading applications, while the rest of us can work with a scenegraph enabled FX. Once Oracle release this code and the platform, I bet that Java on the desktop will be blooming fast! Then all they need to do is port it to devices. Ok Apple won't allow byte code interpreters or virtual machines to run in their walled garden with Java or even Flash. However If Oracle ever makes a deal with Google, and then with Android, to port the JavaFX runtime over there to those mobile devices. I think we will be laughing really hard. Finally JavaFX is still based on ideal of WORA, your JavaFX desktop can be with of course modifications be running on JavaFX mobile device if you architected that way.

*PP*