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
>
