Re: How do I read the output of the Pulse Logger?

[Scott Palmer]

In my test I’m running the same application on Windows and Mac, making the same 
changes to the the scene graph, with the same stylesheets. So I don’t 
understand the difference I’m seeing.

Scott

> On Mar 15, 2016, at 12:33 PM, David Grieve  wrote:
> 
> Sometimes the layout might introduce nodes into the scenegraph. If these new 
> nodes also need laid out, CSS is applied to those nodes since style can 
> affect layout. I would expect CSS overhead to be very small unless there are 
> many new nodes being added to the scene 
> (https://bugs.openjdk.java.net/browse/JDK-8151756 notwithstanding)
> 
> On 3/15/16 12:14 PM, Scott Palmer wrote:
>> Is there a guideline somewhere that explains how to read the output of the 
>> Pulse Logger?
>> 
>> For example, what do the two times represent in this PULSE line:
>> 
>>  PULSE: 569 [1459ms:270ms]
>> 
>> At first I guessed is that it was PULSE:   [> time>ms:]
>> but that doesn’t seem to hold up.
>> 
>> What does the first (usually negative) number mean in the Layout Pass line?
>> 
>>  T23 (-1563 +1563ms): Layout Pass
>> 
>>  T23 (1 +4ms): Layout Pass
>> 
>> 
>> I’ve noticed that the output has some notable differences between my Windows 
>> machine and my Mac. On the Mac I don’t seem to be getting the same sort of 
>> CSS Pass information.  I get only one “CSS Pass” per pulse and it is almost 
>> always telling me something near 0ms:
>> 
>>  PULSE: 509 [1404ms:286ms]
>>  T23 (-1404 +1404ms): Layout Pass
>>  T23 (0 +1ms): CSS Pass
>>  T23 (1 +6ms): Layout Pass
>>  T23 (7 +4ms): Update bounds
>>  T23 (11 +0ms): Waiting for previous rendering
>>  T23 (11 +0ms): Copy state to render graph
>> 
>> but on Windows I get two CSS Passes, one is usually 0ms, the other makes 
>> more sense (I’m investigating a performance issue on a Scene with >10k 
>> nodes, so some notable amount of CSS time is expected.):
>> 
>>  PULSE: 2578 [423ms:3362ms]
>>  T35 (-423 +423ms): Layout Pass
>>  T35 (0 +0ms): CSS Pass
>>  T35 (0 +0ms): Layout Pass
>>  T35 (0 +2725ms): CSS Pass
>>  T35 (2725 +402ms): Layout Pass
>>  T35 (3128 +25ms): Update bounds
>>  …
>> 
>> This seems a bit strange, as I would think Layout and CSS would not be 
>> platform specific. Both systems are running 8u72.
>> I’m also finding Layout times on the Mac are higher than I expected - maybe 
>> some CSS time has been rolled in to that log line on the Mac?
>> 
>> Regards,
>> 
>> Scott
> 

Re: How do I read the output of the Pulse Logger?

[David Grieve]

Sometimes the layout might introduce nodes into the scenegraph. If these 
new nodes also need laid out, CSS is applied to those nodes since style 
can affect layout. I would expect CSS overhead to be very small unless 
there are many new nodes being added to the scene 
(https://bugs.openjdk.java.net/browse/JDK-8151756 notwithstanding)


On 3/15/16 12:14 PM, Scott Palmer wrote:

Is there a guideline somewhere that explains how to read the output of the 
Pulse Logger?

For example, what do the two times represent in this PULSE line:

PULSE: 569 [1459ms:270ms]

At first I guessed is that it was PULSE:   [ms:]
but that doesn’t seem to hold up.

What does the first (usually negative) number mean in the Layout Pass line?

T23 (-1563 +1563ms): Layout Pass

T23 (1 +4ms): Layout Pass


I’ve noticed that the output has some notable differences between my Windows 
machine and my Mac. On the Mac I don’t seem to be getting the same sort of CSS 
Pass information.  I get only one “CSS Pass” per pulse and it is almost always 
telling me something near 0ms:

PULSE: 509 [1404ms:286ms]
T23 (-1404 +1404ms): Layout Pass
T23 (0 +1ms): CSS Pass
T23 (1 +6ms): Layout Pass
T23 (7 +4ms): Update bounds
T23 (11 +0ms): Waiting for previous rendering
T23 (11 +0ms): Copy state to render graph

but on Windows I get two CSS Passes, one is usually 0ms, the other makes more 
sense (I’m investigating a performance issue on a Scene with >10k nodes, so 
some notable amount of CSS time is expected.):

PULSE: 2578 [423ms:3362ms]
T35 (-423 +423ms): Layout Pass
T35 (0 +0ms): CSS Pass
T35 (0 +0ms): Layout Pass
T35 (0 +2725ms): CSS Pass
T35 (2725 +402ms): Layout Pass
T35 (3128 +25ms): Update bounds
…

This seems a bit strange, as I would think Layout and CSS would not be platform 
specific. Both systems are running 8u72.
I’m also finding Layout times on the Mac are higher than I expected - maybe 
some CSS time has been rolled in to that log line on the Mac?

Regards,

Scott

How do I read the output of the Pulse Logger?

[Scott Palmer]

Is there a guideline somewhere that explains how to read the output of the 
Pulse Logger?

For example, what do the two times represent in this PULSE line:

PULSE: 569 [1459ms:270ms]

At first I guessed is that it was PULSE:   [ms:]
but that doesn’t seem to hold up.

What does the first (usually negative) number mean in the Layout Pass line?

T23 (-1563 +1563ms): Layout Pass

T23 (1 +4ms): Layout Pass


I’ve noticed that the output has some notable differences between my Windows 
machine and my Mac. On the Mac I don’t seem to be getting the same sort of CSS 
Pass information.  I get only one “CSS Pass” per pulse and it is almost always 
telling me something near 0ms:

PULSE: 509 [1404ms:286ms]
T23 (-1404 +1404ms): Layout Pass
T23 (0 +1ms): CSS Pass
T23 (1 +6ms): Layout Pass
T23 (7 +4ms): Update bounds
T23 (11 +0ms): Waiting for previous rendering
T23 (11 +0ms): Copy state to render graph

but on Windows I get two CSS Passes, one is usually 0ms, the other makes more 
sense (I’m investigating a performance issue on a Scene with >10k nodes, so 
some notable amount of CSS time is expected.):

PULSE: 2578 [423ms:3362ms] 
T35 (-423 +423ms): Layout Pass 
T35 (0 +0ms): CSS Pass 
T35 (0 +0ms): Layout Pass 
T35 (0 +2725ms): CSS Pass 
T35 (2725 +402ms): Layout Pass 
T35 (3128 +25ms): Update bounds 
…

This seems a bit strange, as I would think Layout and CSS would not be platform 
specific. Both systems are running 8u72.
I’m also finding Layout times on the Mac are higher than I expected - maybe 
some CSS time has been rolled in to that log line on the Mac?

Regards,

Scott

Re: [9] Review request for FX Jigsaw changes

[Vadim Pakhnushev]

Looks good to me.

Vadim

On 15.03.2016 5:38, Kevin Rushforth wrote:

Please review the webrev for reviewing the jigsaw changes for FX.

https://bugs.openjdk.java.net/browse/JDK-8092093

http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/
http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/

I have separated out the in-progress changes to modules/fxpackager* 
(jdk.packager and jdk.packager.services modules) so they can be 
reviewed separately. However, they will be pushed along with the other 
changes as a single changeset.


These changes are planned to be integrated into FX 9 at the same time 
as the JDK changes are integrated (probably next week). They will be 
synced down to FX 9-dev shortly after that.


Please note the following:

* The required boot JDK to build FX after the Jigsaw integration will 
be JDK 9 build 109. We are not yet able to build with a Jigsaw-based 
JDK 9 as the boot JDK yet, so we will be sticking at JDK 9 build 109 
for a few weeks.


* gradle 2.11 is required to build using JDK 9

* In addition to building JavaFX as modules for use with a 
Jigsaw-capable JDK, we still build the "legacy sdk" using the existing 
pre-Jigsaw layout, including jfxrt.jar, etc. As such, most developers 
during the transition will hopefully not notice too much change.


* If you do want to run tests using the modules, you will need a 
Jigsaw-based JDK with javafx modules included, and point to that with 
a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If you 
actually want to build the JDK (which you will need to do if any 
module dependencies change), we will send out separate instructions. 
These will eventually make it onto the OpenJFX Wiki.


* The fxpackager modules are disabled by default. To enable them, you 
need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules 
and point to that with a JDK9_HOME (likely to be changed to 
JIGSAW_HOME) env variable. Since most developers will not build in 
this mode, you need to set 'gradle -PBUILD_FXPACKAGER' to enable 
building the packager.


* I will refresh the webrev tomorrow afternoon, after making a couple 
of planned changes and reacting to any feedback, and again on 
Wednesday afternoon.


-- Kevin