Usage of Toolkit firePulse

[Tomas Mikula]

I think using Platform.runLater to schedule chunks of work should work.
However, dumping all chunks to the event queue at once will likely delay
the next pulse and event processing. Using the continuation style, where
each chunk schedules the next one, should work IMO.

    interface Continuation {
        abstract Optional<Continuation> step();

        static void schedule(Continuation work) {
            Platform.runLater(() -> {
                work.step().ifPresent(Continuation::schedule);
            });
        }
    }

Now you "just" need to implement your work as the above Continuation
interface, which might be a little tricky, but feasible.

Keep in mind that if your chunks are interspersed with other events, those
events might, in general, interfere with what you set out to do in an
upcoming chunk. (For example, if a chunk was going to add an item to a list
at position 8, but before that chunk was executed, some event caused the
list to shrink to size 5, you will get an IOOBE.)

Regards,
Tomas

On Thu, Sep 24, 2015 at 9:48 AM, Dr. Michael Paus <mp at jugs.org> wrote:

> I also thought about using an AnimationTimer but I see a problem with the
> load balancing there.
> If you do too much in the handle() method, then the pulses will be delayed
> but if you do not do enough,
> your canvas update is unnecessarily stretched and you are wasting time.
> You would have a similar
> problem with the firePulse() method.
>
> Am 24.09.15 um 15:13 schrieb Scott Palmer:
>
> 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>
>>> 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] On
>>> Behalf Of Dr. Michael Paus
>>> Sent: Donnerstag, 24. September 2015 11:07
>>> To: 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] On
>>>> Behalf Of Jonathan Giles
>>>> Sent: Donnerstag, 24. September 2015 01:49
>>>> To: 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
>>>>
>>>
>