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....@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-boun...@openjdk.java.net] On
Behalf Of Dr. Michael Paus
Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@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-boun...@openjdk.java.net] On
Behalf Of Jonathan Giles
Sent: Donnerstag, 24. September 2015 01:49
To: openjfx-dev@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
