WebView capabilities review

[Richard Bair]

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