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 >
