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!
11 Replies to “JavaFX in the browser”
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? 🙂
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
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.
The sample is here:
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…
Et voila http://i.imgur.com/LJVohPd.png
OpenJDK; Avian, interpreter mode; Emscripten, SDL2, WebGL.
Nice! Do you have it online somewhere?
Check out your email. Don’t want to put it in public just yet.
Screw it, there’s no reason to wait for anything: https://github.com/lostdj/Jaklin
Wow, that is very impressive! Looking forward to dig deeper into the code. 🙂
Eeh. It’s an impressive mess. 🙂
Comments are closed.