Usage of Toolkit firePulse
Dr. Michael Paus
mp at jugs.org
Fri Sep 25 09:24:44 UTC 2015
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