Usage of Toolkit firePulse

Dr. Michael Paus mp at
Fri Sep 25 16:12:16 UTC 2015

I updated the file on dropbox with the additions made by Tomas.

Am 25.09.15 um 16:57 schrieb Anthony Vanelverdinghe:
> Hi Michael
> Would you mind to share your updated test program through dropbox please?
> Kind regards
> Anthony Vanelverdinghe
> On 25/09/2015 11:24, Dr. Michael Paus wrote:
>> Hi,
>> this really works great and is in my opinion the best approach to ensure
>> a super smooth canvas update. So the trick is to spread the whole 
>> work over
>> several smaller chunks via Platform.runLater calls but instead of 
>> creating
>> all these chunks at once, one has to chain these in such a way that the
>> first call issues the next call at the end if there is still more 
>> work to do. This way
>> there is never more than one call in the queue and the pulses to update
>> the scene graph are not delayed. I think this may become a general 
>> pattern
>> of how to update a canvas with complex drawings.
>> Michael
>> Am 25.09.15 um 00:03 schrieb Tomas Mikula:
>>> Hi Michael,
>>> attached see your original file updated with the continuation-style 
>>> solution.
>>> Regards,
>>> Tomas
>>> On Thu, Sep 24, 2015 at 2:44 PM, Dr. Michael Paus <mp at 
>>> <mailto:mp at>> wrote:
>>>     I have written a little test program to evaluate the various
>>>     strategies which have
>>>     been discussed here. You can download it via this link:
>>> <>
>>>     The program creates a large canvas inside a scroll pane and fills
>>>     it with some
>>>     butterflies. When you scroll the pane the canvas is redrawn when a
>>>     certain
>>>     threshold is exceeded. With some boolean flags at the top of the
>>>     program
>>>     you can select the redraw strategy.
>>>     This was just a quick and dirty hack, so I hope I haven't made any
>>>     mistakes
>>>     but the result so far is that only the AnimationTimer strategy
>>>     leads to a amazingly
>>>     smooth result. For all other strategies the scrolling performance
>>>     is terrible.
>>>     (I have not yet tried the proposal from Tomas.)
>>>     Give it a try yourself. The initial setting are for AnimationTimer.
>>>     Michael
>>>     Am 24.09.15 um 17:17 schrieb Kevin Rushforth:
>>>         Yes, I think this might be a better approach.
>>>         -- Kevin
>>>         Scott Palmer wrote:
>>>             For some of these use cases I wonder if an AnimationTimer
>>>             could be used to handle spreading work out.
>>>             E.g in the case of rendering to a canvas across multiple
>>>             pulses, do a bit at a time in the AnimationTimer’s
>>>             handle() method.
>>>             Scott
>>>                 On Sep 24, 2015, at 5:53 AM, Fisher, Robert
>>>                 <robert.fisher.ext at
>>>                 <mailto:robert.fisher.ext at>> wrote:
>>>                 I was naively thinking something like:
>>>                 1. Make small change to canvas
>>>                 2. Fire pulse
>>>                 3. Make next small change to canvas
>>>                 4. Fire pulse
>>>                 5. Etc..
>>>                 But I was actually also unaware of this firePulse
>>>                 method until this morning (and I couldn't have used it
>>>                 anyway since it's not public API).
>>>                 -----Original Message-----
>>>                 From: openjfx-dev
>>>                 [mailto:openjfx-dev-bounces at
>>> <mailto:openjfx-dev-bounces at>] On
>>>                 Behalf Of Dr. Michael Paus
>>>                 Sent: Donnerstag, 24. September 2015 11:07
>>>                 To: openjfx-dev at
>>>                 <mailto:openjfx-dev at>
>>>                 Subject: Re: Usage of Toolkit firePulse
>>>                 Hi,
>>>                 I wasn't aware of this Toolkit method when I wrote the
>>>                 mail you are referring to. Can you or anybody else
>>>                 explain what this method exactly does. It sounds
>>>                 indeed as if I could solve some problems with it
>>>                 although I am not sure yet and of course only if
>>>                 Jonathan does not block it in the future :-) Michael
>>>                 Am 24.09.15 um 09:31 schrieb Fisher, Robert:
>>>                     I think it would be great to have in the public
>>>                     API. It looks like it would allow you to spread
>>>                     large UI updates out over several pulses in a
>>>                     well-defined way.
>>>                     See also this post from a month or so ago:
>>>                         Hi,
>>>                         I want to do some performance tuning of a
>>>                         JavaFX application of mine but before I can
>>>                         start with that I have to learn a little bit
>>>                         about the scene graph redraw handling.
>>>                         Maybe there is someone on this list who can
>>>                         help me there.
>>>                         What I want to achieve is a super smooth
>>>                         animation (movement) of my scene graph.
>>>                         Let's assume the scene graph itself can be
>>>                         redrawn fast enough in less than 1/60s.
>>>                         In addition let's assume the scene graph
>>>                         contains a canvas which only has to be updated
>>>                         from time to time but an update of the canvas
>>>                         takes substantially longer.
>>>                         Let's say it takes 1s.
>>>                         When an update of the canvas is in progress
>>>                         will this delay the next pulse until all
>>>                         internal drawing within the canvas is
>>>                         finished? From my observations I think so.
>>>                         If I submit my drawing calls to the canvas in
>>>                         smaller chunks via Platform.runLater calls
>>>                         will these also delay the next pulse or will
>>>                         the execution of these calls be delayed in
>>>                         favor of the scene graph update?
>>>                         I hope my goal has become clear. I would like
>>>                         to be able to spread the update of the canvas
>>>                         over several scene graph redraw cycles so that
>>>                         an animation of the canvas stays smooth
>>>                         although the content builds up more slowly.
>>>                         Michael
>>>                     -----Original Message-----
>>>                     From: openjfx-dev
>>> [mailto:openjfx-dev-bounces at
>>> <mailto:openjfx-dev-bounces at>] On
>>>                     Behalf Of Jonathan Giles
>>>                     Sent: Donnerstag, 24. September 2015 01:49
>>>                     To: openjfx-dev at
>>> <mailto:openjfx-dev at>
>>>                     Subject: Usage of Toolkit firePulse
>>>                     Hi all,
>>>                     Today I am keen to get your help on understanding
>>>                     use of the
>>>                     Toolkit.getToolkit().firePulse() private API. If
>>>                     you could spare a few minutes to grep your source
>>>                     directory for any usage of 'firePulse', and email
>>>                     me your findings, that would be really interesting.
>>>                     As a gentle motivational tool I'll conclude by
>>>                     saying that, surprisingly, this private API is
>>>                     barely used inside the openjfx production code. If
>>>                     you look at the openjfx unit tests, it is used
>>>                     massively. The question is - how much is this
>>>                     being used by other community members. If the
>>>                     answer is 'not much' or less, then this private
>>>                     API may not be made public in JDK 9. Your feedback
>>>                     therefore is critical!
>>>                     Thanks,
>>>                     -- Jonathan

More information about the openjfx-dev mailing list