Tetronis, if you supply minimal, executable example code to replicate the issue you might get more responses or a response that could be of more assistance to you.
1. Do you have any api that shows the execution queue of JavaFX ?
There is no public API which shows the pending runnables that have been submitted via runLater. You would have to create such a thing yourself if you wanted it.
2.Is possible to 'jump the queue and make the screen updating immediately ?
The pending runnables are not guaranteed to be executed in any particular order, there is no provision to schedule a pending runnable with higher priority than previously scheduled runnables.
You shouldn't really be submitting either so many runnables within a single pulse or runnables that require so much processing that either of those two things you are asking for is really required.
In my program I have one service that is receiving information from the sports scholarship every 250 ms, and more than 10 other critical services getting every 1 second other information.
In JavaFX, to juggling here because excess Runnable.later increases the consumption of CPU and the program ends up being slow.
Regarding the screen update immediately, I think the hardworking staff JavaFX should see it with affection.
I wonder where'm erring on JavaFX and how to fix these problems
1. I understand that JavaFX is still maturing process and ask, would even Runnable laters a good idea?
2.Retained Mode and 'even better than Immediate Mode, it is worth remembering that in Swing never had this headache?
3. I'm a senior programmer in java, but I confess that in JavaFX'm a baby and you Jsmith, I have read a lot of your answers and understand that you have far more knowledge than me, what do you recommend me to do in a mission-critical program immediate screen update?
I renew my thanks to his person.
> In my program I have one service that is receiving information from the sports scholarship every 250 ms, and more than 10 other critical services getting every 1 second other information.
That amount of updates sounds find and would not seem to me that it should lead to serious performance issues such as you describe. So it is likely the nature of the work you are submitting that is causing an issue rather than the frequency of updates submitted.
> Runnable.later increases the consumption of CPU and the program ends up being slow.
Actually it doesn't really increase CPU consumption, it just schedules something for execution later, so whether the work was done immediately or later, the total work done should remain essentially the same as the overhead of the scheduling is negligible.
> 1. I understand that JavaFX is still maturing process and ask, would even Runnable laters a good idea?
Platform.runLater(runnable) is really the only way for another thread to submit work to be performed on the JavaFX application thread and all modifications to the JavaFX scene graph must be performed on the JavaFX application thread, so there isn't really much choice here.
You could create a complex tree of new nodes in another thread in parallel and then add that entire tree to your active scene or switch your active scene using Platform.runLater, but it isn't at all clear that such an approach would benefit you here.
> 2.Retained Mode and 'even better than Immediate Mode, it is worth remembering that in Swing never had this headache?
JavaFX does have a canvas node which is similar from an application programmer's point of view to an immediate mode. In the end though, I think the implementation is for the JavaFX system to internally batch up all of the drawing commands to an internal buffer, which it periodically flushes on each pulse, so it is not exactly an immediate mode in it's implementation. I have never really done much Swing programming, but my understanding is that Swing implements a single threaded processing architecture for graphics related operations, so it is similar to JavaFX in that respect. I know that other systems such as AWT (and perhaps Java2D) did not enforce a single threaded architecture, but in my experience and that of others, a multi-threaded GUI architecture exposed to application developers often causes more problems than it solves (Multithreaded toolkits: A failed dream? Blog).
> 3. ... what do you recommend me to do in a mission-critical program immediate screen update?
Create an mcve http://stackoverflow.com/help/mcve and post it here or (probably even better) on StackOverflow. Make sure that what you post is:
- complete and can execute on its own.
- demonstrates the issue at hand.
- has been made absolutely minimal in size to demonstrate only the issue and nothing else.
Especially if you post on StackOverflow, you will likely get replies as long as the question is well written and the code is small and clear.
Soon I will make a summary of the java code for friends interested in JavaFX may have problem of science in question.
I understand how you are passionate about JavaFX and I also like, but ... some things need improvement and I will show it soon.
Regarding "stackoverflow.com" I did my registration.