Well what about these use cases? 1. You have a ListView whose cells contain some graphics and are not lightning-fast to render. You also have a TextField at the top that filters the ListView content, i.e. a standard filtered list. When the user types something in the TextField you may want to first update the TextField in the next pulse, and then update the ListView in the following pulse. Imagine the TextField has a “x” in it and no items are showing in the list. Then the user deletes the x and all items should be shown in the list. If the TextField and ListView are updated in the same pulse it will feel laggy. Users expect TextFields to be responsive.
2. You have a ComboBox where you select something and some complex graphics are loaded. You want the ComboBox to disappear immediately in the next pulse, and the graphics to be loaded in the following pulse, otherwise it will feel laggy. Maybe there is a better way to solve these problems? At least with Platform.runLater I didn’t have much success, the behavior is not well-defined. From: Johan Vos [mailto:johan....@gluonhq.com] Sent: Donnerstag, 24. September 2015 09:49 To: Fisher, Robert Cc: jonathan.gi...@oracle.com; openjfx-dev@openjdk.java.net Subject: Re: Usage of Toolkit firePulse I have to admit I use firePulse() occasionally but only when for some reasons a pulse isn't triggered while I expected it. That is a very bad usecase for having this as an API, as I would rather have to investigate why changes to the scenegraph don't result in a pulse. If firePulse() is a public API, what would be the JavaDoc? What would be a recommended situation where one should use this? I think the mail that was referred to previously talks about different update frequencies for different components. I think that is a very good idea, but it seems to me this won't be solved by having a public firePulse API? - Johan On Thu, Sep 24, 2015 at 9:31 AM, Fisher, Robert <robert.fisher....@zeiss.com<mailto:robert.fisher....@zeiss.com>> wrote: 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
