WebView capabilities review

Felix Bembrick felix.bembrick at gmail.com
Tue Jul 23 13:06:44 PDT 2013

I have been evaluating the capabilities of WebView in Java 8 with some
interesting results.

I have basically tested a few different types of web sites using not just
JavaFX WebView but also Qt WebView and Firefox itself.  For those who don't
know, Qt is a leading C++ framework and their WebView component is
implemented using WebKit just like the one in JavaFX.  For my tests both
JavaFX and Qt were 64-bit versions.

The 3 web sites I have tested with are:

1. google.com.au (simple standard web site)
2. maps.google.com.au (because this embraces several web technologies)
3. famo.us (for graphics rendering and JavaScript performance)

For (1) I found that all web views performed about the same with excellent
load times and performance.

For (2) I found that JavaFX WebView and Firefox both loaded quickly and did
a very good job of rendering the maps and handling user interaction.  The
Qt WebView loaded a lot slower and did not feel as responsive once the map
had loaded.  It also suffers from a number of bugs relating to mouse event

For (3) I found that Firefox was a clear winner in terms of both load times
and rendering performance.  Qt WebView was a very close second with only
the load time and some minor graphics artefacts letting it down.  JavaFX
WebView however was absymal with this site being virtually unusable in this
web view because the graphics rendering is very, very slow and reactions to
user interaction also slow.

So now I am very curious as to why (3) performs so slowly in JavaFX
WebView.  This is actually the kind of web page that I need to be able to
display in WebView so I am keen to help in isolating the problem and fixing
it (if possible).

I have come up with a list of possible reasons behind the performance

1. It's WebKit itself or the way JavaFX wraps WebKit.
2. It's the graphics layer of JavaFX that is not optimised enough yet.
3. It's a 64-bit thing because JIT is not enabled in 64-bit WebKit (but why
does it only impact the JavaFX implementation?)
4. It's simply because C++ is faster than Java.
5.It's some other reason.

Does anyone have any theories as to which one it is?  Do these performance
issues have any implications of JavaFX performance as a whole?



More information about the openjfx-dev mailing list