Paint Phase Debugging / Performance

Matthew Elliot matthew.james.elliot at
Tue May 1 18:06:47 UTC 2018

Hi all,

The last few days I was troubleshooting a new performance issue that showed
up in our PROD application where customers had fallen back to the SW
rendering pipeline. It severely affected the application where CPU
frequency was under 3 GHz with hover lags of a few seconds in the worst
cases. With thousands of potential HW/SW combinations in the wild it took
quite a while to even identify it really was an issue in our application
and not the usual noise of some silly set up. All this got me thinking...

... what was visible was long paint passes, and long waiting on previous
render but narrowing this down to exactly what was going on took a lot of
manual inspection of the rendering pipeline code / debugging and somewhat
by chance I stumbled over the -Dprism.disableEffects flag which after much
more pain helped me narrow down the issue.

The root cause turned out to be an -fx-effect (blend, inner shadow) on an
animated node that was set from the code by an unknowing developer.

While there are tools like mission controller for visualising the pulse and
phases it can be difficult to identify for example what is going wrong
inside of the painting phase and it is difficult to control that nothing
bad happens when many developers can make changes to the code and reviews
will never catch everything... I'm therefore thinking about ways to run
rendering tests in continuous integration that would fail fast if the SW
rendering pipeline would get overloaded.
I had a look at PulseListener where I could see pulse times but I'd like to
go more detailed and actually like the information tracked in the internals
of PulseLogger (PulseData) without doing any nasty tricks.

I thought maybe somebody has already thought about this problem before and
maybe there is even some tooling around this beyond the logging? I could
even imagine using the same technique to monitor the rendering pipeline in
real time and alerting us (maybe even the user) if things are going a bit

Maybe more generically, how do you even start to debug delays in the paint
phase? Timed breakpoints and IDE assisted debug logging aside. :)


PS: It might even be nice to tell the Painter to give up after N ms (prism
setting?). Sometimes better to break than to not be useable because of
paint phases taking 200-300 ms and JavaFX Application Thread thread getting
almost starved completely.

More information about the openjfx-dev mailing list