Usage of Toolkit firePulse
Dr. Michael Paus
mp at jugs.org
Fri Sep 25 16:12:16 UTC 2015
Hi,
I updated the file on dropbox with the additions made by Tomas.
Michael
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 jugs.org
>>> <mailto:mp at jugs.org>> 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:
>>>
>>> <https://www.dropbox.com/s/vmg9nyn7pdfk4b1/SmoothButterflies.java?dl=0>
>>>
>>> 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 zeiss.com
>>> <mailto:robert.fisher.ext at zeiss.com>> 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 openjdk.java.net
>>> <mailto:openjfx-dev-bounces at openjdk.java.net>] On
>>> Behalf Of Dr. Michael Paus
>>> Sent: Donnerstag, 24. September 2015 11:07
>>> To: openjfx-dev at openjdk.java.net
>>> <mailto:openjfx-dev at openjdk.java.net>
>>> 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 openjdk.java.net
>>> <mailto:openjfx-dev-bounces at openjdk.java.net>] On
>>> Behalf Of Jonathan Giles
>>> Sent: Donnerstag, 24. September 2015 01:49
>>> To: openjfx-dev at openjdk.java.net
>>> <mailto:openjfx-dev at openjdk.java.net>
>>> 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