Re: Paint Phase Debugging / Performance

[Matthew Elliot]

Hey Nir,

In MissionControl the HotMethods section is very interest sometimes; not sure 
if that is where you’re already looking. It might point at the particular part 
of rendering pipeline that is executing too much.

I assume you also captured the JavaFX events and visualised the 
FXApplicationThread and QuantumRenderer threads to see that QuantumRenderer is 
constantly busy. 

I also don’t know how many animations you have but we also introduced a single 
central animation which modified properties triggering other components to 
redraw. This meant we only had 1 animation instead of dozens or hundreds. Not 
sure if this makes such a big difference to painting. 

Maybe also worth trying is in the IDE (I.e. IntelliJ) to Instrument the code 
with the debugger by evaluate and logging timestamps in the code. If you look 
at breakpoint properties you can put inside ‘Evaluate and log’ block 
System.currentTimeMillis(). Not sure how much it’ll drag performance back but 
maybe on prism frames per second = 1 and many breakpoints in the painting 
pipeline you can at least find where it spends all the time. 

Beyond that I’d be out of ideas. 
Matt

Sent from my phone.

> On 9/05/2018, at 1:15 AM, Nir Lisker  wrote:
> 
> Hi Matthew,
> 
> This is a typical pulse, which indeed cases the effect of low FPS, and that's 
> what I'm trying to solve.
> 
> * Cache hints are ignored for 3D (but I tried anyway).
> * -Dprism.showdirty and printrendergraph also don't work for 3D scenes 
> (though I can get an approximation with a 2D scene).
> * There are no effects.
> 
> I'm working with Mission Control already, most of the instances in the GC 
> class histogram are related to animation classes: 
> InterpolationInterval$TangentDoubleInterpolationInterval and 
> NumberTangentInterpolator.
> 
> Looks like all all the discussed difficulties with diagnostics are enhanced 
> when it comes to 3D. Will have to dig deep on this one.
> 
> Thanks,
> Nir
> 
>> On Mon, May 7, 2018 at 9:07 PM, Matthew Elliot 
>>  wrote:
>> Hey Nir,
>> 
>> I’m not sure if I can offer much support as I haven’t been into the 3D world 
>> but just to clarify, is it one pulse after another with long wait, paint 
>> phases? From what I’ve seen personally if you have painting of 100+ 
>> milliseconds on every pulse you will be in big trouble / laggy as. 
>> 
>> On a one-off pulse like building a scene the first time I would say it is 
>> fine but regular paints that are longer are going to cause issues from my 
>> experience.
>> 
>> Did you try profiling with mission controller to look at what garbage is 
>> being created / what hot methods there? Maybe it points you in a better 
>> direction / at least rule out your own code. 
>> 
>> With animations I guess you set cache hints already?
>> 
>> Make sure you don’t have any effects on the animation as well, a Gaussian 
>> blur blend/drop shadow on an animation killed it for me. 
>> You can also try -Dprism.disableEffects= true to rule it out. 
>> You can also enable the prism option to show what is being painted on each 
>> pulse as an overlay. -Dprism.showdirty and there is another I forget to show 
>> how many times it was painted. (Not that your whole scene is painted when 
>> you expect a small part of it)
>> 
>> Or some trial and error with the prism flags here to try narrow it down - 
>> Just open PrismSettings.java in your IDE or web browser. 
>> 
>> Code explains them better than most posts I’ve seen.
>> 
>> Good luck. 
>> Matt
>> 
>> Sent from my phone.
>> 
>>> On 7/05/2018, at 2:36 PM, Nir Lisker  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm having a performance issue myself. I'm using animations on 3D models 
>>> (in a 3D subscene) and when there are "too many" models the QuantumRenderer 
>>> thread is running 100% of the time and utilizing 20-25% of the CPU, though 
>>> the OS reports that overall all cores are at ~40%. The application is using 
>>> the d3d pipeline.
>>> 
>>> A typical pulse is
>>> 
>>> PULSE: 4078 [112ms:225ms]
>>> T15 (11 +0ms): CSS Pass
>>> T15 (11 +0ms): Layout Pass
>>> T15 (12 +0ms): Update bounds
>>> T15 (12 +95ms): Waiting for previous rendering
>>> T15 (108 +0ms): Copy state to render graph
>>> T12 (109 +115ms): Painting
>>> T12 (224 +0ms): Presenting
>>> Counters:
>>> Nodes rendered: 651
>>> Nodes visited during render: 651
>>> 
>>> Thread dumps show that QuantumRenderer is busy with tasks inside
>>> 
>>> at 
>>> com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.graphics@10-internal/BaseMesh.java:584)
>>> at 
>>> com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics@10-internal/BaseMesh.java:516)
>>> at 
>>> com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics@10-internal/NGTriangleMesh.java:75)
>>> at 
>>> com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics@10-internal/NGShape3D.java:84)
>>> at 
>>> 

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Kevin Rushforth]

Hi Prasanta,

The API looks good now.

All of our automated tests work (except for the ones with a security 
manager due to JDK-8202451 
).


The only functional problem that I see is that Drag and Drop onto a 
SwingNode doesn't work. We need to make sure that we test the following 
four cases:


1. Drag / drop onto a Swing component in a SwingNode
2. Drag / drop from a Swing component in a SwingNode
3. Drag / drop onto a JavaFX control in a JFXPanel
4. Drag / drop from a JavaFX control in a JFXPanel

So far I only tried the first one; the others still need to be validated.

-- Kevin



On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to this

http://cr.openjdk.java.net/~psadhukhan/fxswing.12/

Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes 
to java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an 
empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. 
Should be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with 
one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is 
not an instance of SunGraphics2D. The former behavior was to leave 
the instance variables X and Y unchanged. The new behavior will set 
them back to 1.0. Maybe this can't happen in practice, but it is 
something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Kevin Rushforth]

I just checked, and it looks like the build doesn't generate docs for 
the jdk.unsupported.desktop module. So the issue of doclint warnings is 
probably a moot point.


-- Kevin


On 5/9/2018 7:42 AM, Philip Race wrote:

Yes, they (the methods mentioning Peer) should be renamed.

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious 
listing of

it as a module nor classification of it.

Another thing that Kevin & I touched on in conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.

-phil.

On 5/9/18, 5:28 AM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes 
to java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an 
empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. 
Should be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with 
one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is 
not an instance of SunGraphics2D. The former behavior was to leave 
the instance variables X and Y unchanged. The new behavior will set 
them back to 1.0. Maybe this can't happen in practice, but it is 
something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[mandy chung]

On 5/9/18 7:48 AM, Alan Bateman wrote:

On 09/05/2018 15:42, Philip Race wrote:

:

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious 
listing of

it as a module nor classification of it.
Right, it's not necessary to list modules that are defined to the 
application class loader and are only in the JDK image. There's a 
comment at the top of the make file on this but it probably could be a 
bit clearer.


The build determines the modules to be compiled from the source 
directory per the modular source layout.  make/common/Modules.gmk serves 
a few purpose and the relevant one here is the module to class loader 
mapping.  It lists the modules defined to the boot loader and platform 
boot loader.


Mandy

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Alan Bateman]

On 09/05/2018 15:42, Philip Race wrote:

:

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious 
listing of

it as a module nor classification of it.
Right, it's not necessary to list modules that are defined to the 
application class loader and are only in the JDK image. There's a 
comment at the top of the make file on this but it probably could be a 
bit clearer.


-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Philip Race]

Yes, they (the methods mentioning Peer) should be renamed.

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious listing of
it as a module nor classification of it.

Another thing that Kevin & I touched on in conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.

-phil.

On 5/9/18, 5:28 AM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to 
java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an 
empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. Should 
be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with 
one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is not 
an instance of SunGraphics2D. The former behavior was to leave the 
instance variables X and Y unchanged. The new behavior will set them 
back to 1.0. Maybe this can't happen in practice, but it is 
something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Prasanta Sadhukhan]

Modified webrev to cater to this

http://cr.openjdk.java.net/~psadhukhan/fxswing.12/

Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to 
java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an 
empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. Should 
be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with 
one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is not 
an instance of SunGraphics2D. The former behavior was to leave the 
instance variables X and Y unchanged. The new behavior will set them 
back to 1.0. Maybe this can't happen in practice, but it is 
something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Kevin Rushforth]

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods with 
"Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to 
java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an empty 
body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. Should 
be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with one 
observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is not 
an instance of SunGraphics2D. The former behavior was to leave the 
instance variables X and Y unchanged. The new behavior will set them 
back to 1.0. Maybe this can't happen in practice, but it is something 
to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Hi,
I investigated the issue of using the standalone JavaFX SDK inside of an 
IDE (Eclipse and IntelliJ) a little bit further. For this purpose I used 
a simple single-class JavaFX program (actually the one which Johan used 
too).


I started with Eclipse, created a simple Java project, added the JFX 
jars to the module path and added the --add-modules command to the 
runtime configuration. The result is: this works at compile time but not 
at runtime.


Then I tried the same with IntelliJ. (I have to admit though that I have 
never seriously used IntelliJ before.) I created the project, added the 
dependencies and configured the runtime. The result is: the same error 
as in Eclipse.


The advantage of IntelliJ though is that it directly shows you the 
command line which was created to launch the application. The problem 
seems to be that IntelliJ (in the same way as Eclipse) just puts the 
JavaFX dependencies on the classpath and not on the module path. The 
only way I found to fix this was to add a module-info.java to the project.


module projavafx.helloearthrise.ui {
    requires javafx.graphics;
    requires javafx.controls;
    exports projavafx.helloearthrise.ui;
}

After that you don't need the --add-modules command anymore.

After adding this the setup immediately worked in IntelliJ. In Eclipse 
however the program could now be launched and there was no error or 
warning but the program just hangs and does not show anything on the 
screen. By looking at the generated command line via "ps -ef | grep 
java" I found that Eclipse is adding this option "-XstartOnFirstThread" 
which makes the program hang. There is a switch in the Eclipse runtime 
configuration dialog, which is selected by default, and which causes 
Eclipse to use this option when it thinks it is launched with SWT. This 
is caused by the fact that I have created a library (like Nir suggested) 
into which I put all jars of the JavaFX SDK, also the javafx-swt.jar one 
although it is not needed here. This has never been a problem before the 
split between JDK and JFX. This problem can be fixed by either switching 
off the startOnFirstThread option in the runtime configuration or by 
just not adding the javafx-swt.jar.


So, my conclusion for the moment is that you can only use the split 
JDK/JFX in Eclipse/IntelliJ when your main project has a 
module-info.java. This may be a problem if you are not yet ready or 
willing to modularize your application.


If somebody knows a trick to get around this limitation I'd be happy to 
here about it.


Michael


Am 08.05.18 um 14:39 schrieb Michael Paus:

Am 08.05.18 um 14:27 schrieb Tom Schindl:

[...]


3. How do you properly configure an Eclipse (the latest 4.7.3a) project
to use this module path. Adding the OpenJDK was no problem but how do
you add the module path for JavaFX? I failed on that.


You just open the Java Build Path-Properties-Page on the project and add
the external jars, not?

Tom


That's one of the ways I tried it but ...

1. is that the intended way of doing it? On the command line you just 
specify a single folder.


2. I did this and it resolved all dependencies at compile time but I 
got an exception at runtime


Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.fxml not found

although I also added

--add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media

as VM arguments.

[11] RFR : JDK-8196844 : [TestBug] IllegalArgumentException gets logged in some of test.javafx.scene.* tests

[Ambarish Rapte]

Hi Kevin & Ajit,

 

Please review this test fix:

Webrev: http://cr.openjdk.java.net/~arapte/fx/8196844/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8196844

 

Regards,

Ambarish

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Prasanta Sadhukhan]

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to 
java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an empty 
body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. Should 
be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with one 
observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is not 
an instance of SunGraphics2D. The former behavior was to leave the 
instance variables X and Y unchanged. The new behavior will set them 
back to 1.0. Maybe this can't happen in practice, but it is something 
to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan