JavaFX in the browser

Screenshot JavaFX in the browser
Screenshot JavaFX in the browser

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/

11 responses to “JavaFX in the browser”

  1. […] Heinrichs has blogged about rendering JavaFX content in the browser (without the use of any applet technology – just straight HTML and […]

  2. nobody Avatar
    nobody

    Hey, this is very nice. Did you modify JFX in any other way, beside introducing new renderer?

    Also, what about threads? Did you hand off all the MT handling to Doppio (I guess it emulates them with green threads?..), or modified JFX to run on only one thread? Can I haz code plz? 🙂

  3. FilterPunk Avatar
    FilterPunk

    Will you turn this into a community project? Do you have any plans on putting up github/bitbucket repository?
    Have you had a look into monocle and porting monocle to webgl? Also Richard Bair had already talked about experience of porting JavaFX: http://markmail.org/message/o2ttsejmcdtc6jfi

  4. Mike Avatar

    Hi, thanks for your kind words.

    I did not modify the JavaFX runtime very much. It was mostly about adding stuff, e.g. another build configuration and another platform. The only real change I remember was disabling DatePicker, because it uses the new Data and Time API, which is not available on Doppio yet.

    Multithreading is completely handled by Doppio. There are some limitations, but the design of JavaFX fits quite nicely and I have not experienced any issues yet.

    So far I have not thought about turning this into a community project. But if there is serious interest – why not?

    All PoCs are based on Monocle. Currently I work on a PoC that uses the es2 renderer to render into WebGL. But progress is awfully slow, because I have no clue about WebGL and the es2 renderer. 🙂

    Sources are available on BitBucket, though there is no documentation and I doubt there are useful without.
    https://bitbucket.org/michael_heinrichs/jfx8web

    The sample is here:
    https://bitbucket.org/michael_heinrichs/jfx8web-samples

  5. nobody Avatar
    nobody

    Thanks! Commits and diffs are good enough. It’s not like JFX itself has tons of documentation on its internals. 🙂

    I’m currently working on bringing JFX on the web, too. But took a different approach: emscripten + avian. Renderer should not be a problem in theory, WebGL is pretty much the same as ES2. There’s even some EGL support (emulated), if I decide to base the port on Monocle.

    But threads and multiple GL contexts are the problem…

  6. lostdjnobody Avatar
    lostdjnobody

    Et voila http://i.imgur.com/LJVohPd.png

    OpenJDK; Avian, interpreter mode; Emscripten, SDL2, WebGL.

    :>

  7. Mike Avatar

    Nice! Do you have it online somewhere?

  8. nobody Avatar
    nobody

    Check out your email. Don’t want to put it in public just yet.

  9. lostdj Avatar

    Screw it, there’s no reason to wait for anything: https://github.com/lostdj/Jaklin

    1. Mike Avatar

      Wow, that is very impressive! Looking forward to dig deeper into the code. 🙂

  10. lostdj Avatar

    Eeh. It’s an impressive mess. 🙂