W 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) { Application.launch(args); } @Override public void start(final Stage stage) { final BorderPane pane = new BorderPane(); final WebView view = new WebView(); view.getEngine().load("http://famo.us/"); pane.setCenter(view); final Scene scene = new Scene(pane); stage.setScene(scene); stage.show(); } } On 24 July 2013 08:26, Richard Bair <richard.b...@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 >