Paint Phase Debugging / Performance
Nir Lisker
nlisker at gmail.com
Mon May 7 12:36:34 UTC 2018
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 at 10-internal
/BaseMesh.java:584)
at
com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics at 10-internal
/BaseMesh.java:516)
at
com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics at 10-internal
/NGTriangleMesh.java:75)
at
com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics at 10-internal
/NGShape3D.java:84)
at
com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics at 10-internal
/NGShape3D.java:201)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics at 10-internal
/NGNode.java:2379)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal
/NGNode.java:2063)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics at 10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics at 10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics at 10-internal
/NGNode.java:1964)
at
com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics at 10-internal
/ViewPainter.java:479)
at
com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics at 10-internal
/ViewPainter.java:328)
at
com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics at 10-internal
/PresentingPainter.java:91)
at
java.util.concurrent.Executors$RunnableAdapter.call(java.base at 10-internal
/Executors.java:514)
at java.util.concurrent.FutureTask.runAndReset(java.base at 10-internal
/FutureTask.java:305)
at com.sun.javafx.tk.RenderJob.run(javafx.graphics at 10-internal
/RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 10-internal
/ThreadPoolExecutor.java:1135)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 10-internal
/ThreadPoolExecutor.java:635)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics at 10-internal
/QuantumRenderer.java:125)
at java.lang.Thread.run(java.base at 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.elliot at 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 <pedro.duquevieira at gmail.com>
> 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
> >
>
More information about the openjfx-dev
mailing list