WebView capabilities review

Felix Bembrick felix.bembrick at gmail.com
Tue Jul 23 15:38:39 PDT 2013

hat I didn't mention is that with this website famo.us I initially started
with WebView in JavaFX 2.2.5 and it renders the animations but very, very
slowly and is not really usable.

However, with JavaFX 8 b99 it's much, much worse.  Now it doesn't even get
to render the first animation as it just displays a background and
progresses no further.  This looks like some kind of regression.

Are you able to see anything like what is displayed in a standard web
browser for this site when using WebView in JavaFX 8?  Try this test app:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.BorderPane;
import javafx.scene.web.WebView;
import javafx.stage.Stage;

public class WebViewTest2 extends Application {

public static void main(final String[] args) {

public void start(final Stage stage) {
 final BorderPane pane = new BorderPane();
final WebView view = new WebView();
 final Scene scene = new Scene(pane);

On 24 July 2013 08:26, Richard Bair <richard.bair at oracle.com> wrote:

> Hi Felix,
> Thanks, this helps a lot. Let me walk through it:
> PULSE: 1 [0ms:57ms]
> The PulseLogger accumulates data for each pulse that occurs. Here we've
> got:
> PULSE: [pulse number] [[time since end of previous frame]ms:[time this
> pulse took, including time it took waiting for previous pulse]ms]
> So we see that the very first pulse took 57ms to finish (not all of which
> is accounted for in the remaining output)
> T11 (3 +0ms): CSS Pass
> T11 (3 +0ms): Layout Pass
> T11 (4 +0ms): Waiting for previous rendering
>  T11 (4 +7ms): Copy state to render graph
> T9 (25 +0ms): Dirty Opts Computed
> T9 (25 +29ms): Painted
> T11 is thread 11, T9 is thread 9. The numbers will sometimes differ from
> run-to-run or machine-to-machine, but you can see one is the FX thread (T11
> in this case) and one is the render thread (T9).
> Each entry shows the time from the start of the pulse + the time this
> particular operation took. So the CSS pass started 3ms after the start of
> the pulse and lasted 0ms. In particular we see here that 7ms was spent
> copying state to the render graph and 29ms to paint the first pulse.
> Counters:
>  Cached Region background image used: 1
> Nodes rendered: 6
>  Nodes visited during render: 8
> Region background image cached: 1
> These are just helpful counters to tell us stuff. We visited 8 nodes but
> only had to render 6. One background image was cached for regions. Etc
> .
> [4 16ms:2ms][5 1ms:1ms][6 15ms:0ms][7 16ms:0ms][8 16ms:0ms][9 16ms:0ms][10
> 16ms:0ms][11 16ms:0ms][12 16ms:0ms][13 16ms:0ms]
> These are all pulses that happened under the threshold of 17ms. You can
> configure the threshold via -Djavafx.pulseLogger.threshold=30 or whatever.
> So the fact that we're seeing a lot of these means each pulse is going
> quite quickly (that 17ms threshold includes *everything* for the pulse --
> the CSS, Layout, synchronization, picking, rendering -- everything).
> PULSE: 138 [21ms:63ms]
> T11 (36 +0ms): CSS Pass
> T11 (36 +0ms): Layout Pass
> T11 (36 +0ms): Waiting for previous rendering
> T11 (36 +0ms): Copy state to render graph
> T9 (56 +0ms): Dirty Opts Computed
> T9 (56 +7ms): Painted
> Counters:
>  Cached Region background image used: 1
> Nodes rendered: 3
>  Nodes visited during render: 4
> Something happened here that soaked up 36ms before the CSS pass started.
> And something else took up another 20ms between T11 and T9. But the actual
> rendering and scene graph processing appears to have been quite fast. A
> profiler will be needed to find out where else the time is going (maybe
> some of it is in computing bounds? Is that included in the copy state to
> render graph counter?).
> So in all the rest of the output I don't see anything obvious. It may be a
> timing issue -- maybe thread synchronization between web & FX? Peter Z, any
> ideas?
> Richard

More information about the openjfx-dev mailing list