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 <m...@jugs.org
<mailto:m...@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....@zeiss.com
<mailto: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
<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
<mailto: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
<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
<mailto: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
