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

[Prasanta Sadhukhan]

Modified webrev to rename to InteropProviderImpl

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

Regards
Prasanta
On 5/7/2018 8:35 PM, Kevin Rushforth wrote:

That name seems good to me.

-- Kevin


On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote:

Would InteropProviderImpl sound good?

Regards
Prasanta
On 5/7/2018 8:27 PM, Alan Bateman wrote:



On 07/05/2018 10:26, Prasanta Sadhukhan wrote:

:

Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
This looks okay although for consistent then InteropImpl could be 
renamed too.


-Alan

Announcing EA builds of standalone JavaFX SDK

[Kevin Rushforth]

I am pleased to announce the first Early Access build of a standalone 
JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an 
OpenJDK 11 EA build.


If your application is in an unnamed module (i.e., your app is on the 
classpath), you can run your application as follows, after unzipping the 
SDK bundle for your platform.


$ java --module-path $PATH_TO_FX/javafx-sdk-11 
--add-modules=javafx.controls,javafx.fxml MyApp


This assumes you don't need media or web. If you do, then add those 
modules, too. Note that since javafx.web "requires transitive 
javafx.controls", you can omit javafx.controls if you add javafx.web.


If you are running a modular application, then you don't need the 
"--add-modules" option.


Note that this is a stepping stone to javafx modules in a repository 
like Maven.


Please test your applications with the SDK and give us feedback.

Thanks.

-- Kevin

[1] http://jdk.java.net/openjfx/

Re: Paint Phase Debugging / Performance

[Matthew Elliot]

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 
> com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics@10-internal/NGShape3D.java:201)
> at 
> com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal/NGNode.java:2072)
> at 
> com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal/NGNode.java:1964)
> at 
> com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal/NGGroup.java:270)
> at 
> com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal/NGNode.java:2072)
> at 
> com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal/NGNode.java:1964)
> at 
> com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal/NGGroup.java:270)
> at 
> com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal/NGNode.java:2072)
> at 
> com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal/NGNode.java:1964)
> at 
> com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal/NGGroup.java:270)
> at 
> com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics@10-internal/NGNode.java:2379)
> at 
> com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal/NGNode.java:2063)
> at 
> com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal/NGNode.java:1964)
> at 
> com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal/NGGroup.java:270)
> at 
> com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal/NGNode.java:2072)
> at 
> com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal/NGNode.java:1964)
> at 
> com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics@10-internal/ViewPainter.java:479)
> at 
> com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics@10-internal/ViewPainter.java:328)
> at 
> com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics@10-internal/PresentingPainter.java:91)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@10-internal/Executors.java:514)
> at 
> java.util.concurrent.FutureTask.runAndReset(java.base@10-internal/FutureTask.java:305)
> at 
> 

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

[mandy chung]

On 5/7/18 2:26 AM, Prasanta Sadhukhan wrote:

Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/


This version looks good.   InteropProviderImpl name is okay with me.

Mandy

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

[Kevin Rushforth]

That name seems good to me.

-- Kevin


On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote:

Would InteropProviderImpl sound good?

Regards
Prasanta
On 5/7/2018 8:27 PM, Alan Bateman wrote:



On 07/05/2018 10:26, Prasanta Sadhukhan wrote:

:

Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
This looks okay although for consistent then InteropImpl could be 
renamed too.


-Alan

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

[Prasanta Sadhukhan]

Would InteropProviderImpl sound good?

Regards
Prasanta
On 5/7/2018 8:27 PM, Alan Bateman wrote:



On 07/05/2018 10:26, Prasanta Sadhukhan wrote:

:

Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
This looks okay although for consistent then InteropImpl could be 
renamed too.


-Alan

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

[Alan Bateman]

On 07/05/2018 10:26, Prasanta Sadhukhan wrote:

:

Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
This looks okay although for consistent then InteropImpl could be 
renamed too.


-Alan

Re: Paint Phase Debugging / Performance

[Nir Lisker]

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
com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics@10-internal
/NGShape3D.java:201)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics@10-internal
/NGNode.java:2379)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2063)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics@10-internal
/ViewPainter.java:479)
at
com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics@10-internal
/ViewPainter.java:328)
at
com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics@10-internal
/PresentingPainter.java:91)
at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@10-internal
/Executors.java:514)
at java.util.concurrent.FutureTask.runAndReset(java.base@10-internal
/FutureTask.java:305)
at com.sun.javafx.tk.RenderJob.run(javafx.graphics@10-internal
/RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@10-internal
/ThreadPoolExecutor.java:1135)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@10-internal
/ThreadPoolExecutor.java:635)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics@10-internal
/QuantumRenderer.java:125)
at java.lang.Thread.run(java.base@10-internal/Thread.java:844)

Does anyone have an idea on how to continue?

Thanks,
Nir


On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot <
matthew.james.ell...@gmail.com> wrote:

> Hi Pedro,
>
> The first link I have read through many times, it is very useful for ideas
> but doesn't really flesh out or go into much detail on each topic. It also
> comments a few times on the problems we've encountered, 'what costs what'
> is difficult to understand / measure.
>
> The second link I hadn't found my way to and is definitely interesting to
> understand more about how things are working internally - thanks.
>
> Regards,
> Matt
>
>
> On 3 May 2018 at 19:17, Pedro Duque Vieira 
> wrote:
>
> > Hi Matthew,
> >
> > On the topic of documents with indications for improving performance.
> >
> > Don't know if you already found it, but there is a draft here (to which
> > I've made a small contribution):
> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+
> Tips+and+Tricks
> >
> > A bit old though...
> >
> > And here:
> >
> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas
> >
> >
> > --
> > Pedro Duque Vieira
> >
>

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

[Prasanta Sadhukhan]

On 5/6/2018 1:15 PM, Alan Bateman wrote:

On 05/05/2018 16:20, Prasanta Sadhukhan wrote:
Updated webrev to modify java.desktop module-info.java (only 
difference between webrev7 and this) to remove the duplicate exports 
of sun.awt so we will have now


exports sun.awt to
    jdk.accessibility,
    jdk.unsupported.desktop;

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


At a high-level, the module declarations look good and using service 
binding to ensure that the jdk.unsupported.desktop module is resolved 
looks good. The only thing is the name of the service provider 
interface, it might be clearer if you use InteropProvider rather than 
InteropInterface.



Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
I assume dependencies/java.desktop/module-info.java.extra will be 
removed once the remaining dependency on sun.print goes away.



Yes, that's the plan.

Regards
Prasanta

-Alan