Netopyr GmbH

Lately Carl Dea and I have started a new project to bring JavaFX 8 into the browser. Today I want to introduce the first two proof-of-concepts that we created to see if this idea is feasible at all.
For the impatient, here are the links to the PoCs. But be warned, startup time is horrible at this point. It can easily take 1-2 minutes until the JavaFX application starts.
http://jfx8web.netopyr.com/poc1/
http://jfx8web.netopyr.com/poc2/

Both proof-of-concepts show a number of rectangles and circles in different colors. Implementing these shapes gave us a rough understanding of the underlying technology and we gained a first impression of the expected complexity and effort. The proof-of-concepts also include a circle moving back and forth. While this animation is anything but spectacular, it gives us an upper bound of the expected performance. If we are not able to show this simple animation with acceptable performance, we do not need to waste time on more complex animations.

The proof-of-concepts use Doppio at the core, which is just an astonishing project. Doppio is a JVM implemented in JavaScript running in the browser. Which once again proves the coders version of Rule 34: “If you can think of it, there is an implementation in JavaScript…”

To be honest, I was very skeptical of this approach. How good can the performance of such a JVM be? On the other hand, JavaScript became amazingly fast in recent years and as Hendrik Ebbers jokingly pointed out recently, these days nothing gets more aggressively optimized than JavaScript. It was worth a try. As you can see in the PoCs (which hopefully started by now), especially in the second one, runtime performance is surprisingly good. Consider once again what you are looking at: This is a standard JavaFX application compiled into byte code, which is interpreted (AFAIK Doppio does not do JIT so far) in a JVM implemented in JavaScript. And the JavaFX runtime that is used is almost identical to the standard implementation.

Doppio supports Java 6 only, but the JavaFX runtime is based on Java 8. The Doppio team is working hard to support Java 8, but as of now we have to bridge the gap somehow. We decided to use RetroLambda, mainly because the JavaFX port for Android already uses it. It is an extremely useful tool, which takes Java 8-compliant byte code and migrates it to Java 7 or even Java 6 byte code. So far it worked flawless for us, only default methods are not supported yet. I am not sure, if it is production ready, but if you were stuck with Java 6 or Java 7, would like to use Java 8 features, and you have extensive testing in place, it is worth checking out.

The proof-of-concepts use different approaches to render the JavaFX Scene on the screen. The first PoC uses the software renderer. It is part of the JavaFX runtime and, as the name suggests, almost everything to render a scene is done in Java. The result is an array of bytes, which we must copy to the screen. The custom renderer on the other hand tries to use as much of the HTML canvas API as possible, i.e. to render a circle, the custom renderer uses the method arc(). Usually the second approach is much faster, because it can take advantage of optimizations that are part of the platform. But it also means that the implementation will be limited by the possibilities of the platform. For example advanced features with video (e.g. rotation and overlays) and a number of effects are often not supported.

The next steps are at least two more prototypes and then we will decide which route to follow. And we need to fix the startup time. Stay tuned!

http://jfx8web.netopyr.com/poc1/
http://jfx8web.netopyr.com/poc2/