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

Reply via email to