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.
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.
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!