java - Javafx: Difference between javafx.concurent and Platform.runLater? -

i'm curious difference between javafx.concurent , platform.runlater multithreaded javafx programming.

does mean javafx.concurrent, can have multiple actual drawing threads or end on 1 thread anyway?

e.g 1 thing enjoyed using javafx , swing concurrently both used 2 different drawing threads. use swing heavy stuff (e.g. opening filechooser) , use javafx core visual stuff e.g playing seamless, looping video. however, mac makes impossible because of headless exception error fell on javafx , meant lot of pauses when doing things opening filechoosers.

if rewrite app javafx.concurrent, mimic 2 draw thread experience once did swing + javafx?

platform.runlater

a worker complementary platform.runlater.

• use platform.runlater when executing off of javafx application thread , want run logic on javafx application thread.
• use worker when running on javafx application thread , want spawn logic or (especially) i/o on new thread don't block javafx application thread.

you never want network i/o inside platform.runlater's run method, want in worker's call method.

task , service

consider using task or service subclasses of worker. these javafx wrappers futuretask (which in turn runnable). workers provide call method run logic on background thread. maintain execution status (with thread safe callback notification javafx thread state changes) , return results of call via value, message , exception properties.

take advantage of design patterns in task , service javadoc examples simplify creation of thread-safe applications features such as:

• asynchronous fetching of data ui update.
• periodic message updates task progress.
• constructing node graphs not yet attached displayed scene.
• monitoring progress via progress bars, etc.

using workers , platform.runlater together

also, usage of task , service not incompatible use of platform.runlater. instance, if have long running task want return partial results ui periodically or buffer fills, executing platform.runlater in task's call method way that.

working existing threading systems

workers useful when don't have existing threaded service provided library, instead creating own threads execute in background. if have existing threaded service, need use platform.runlater perform logic on javafx application thread.

be careful writing multi-threaded code

note still need know doing, if use worker. must still take care don't violate standard javafx concurrency rules, such never updating nodes on active scene graph (including not updating values nodes in active scene graph bound - such observable list of items backing listview).

answering of addition questions

does mean javafx.concurrent, can have multiple actual drawing threads or end on 1 thread anyway?

there 1 render thread in javafx. cannot make more render threads using javafx concurrent. can things create nodes off javafx thread or set pixels off screen writeableimage or canvas using many threads, every render operation passes through single thread managed javafx system on have no control.

if rewrite app javafx.concurrent, mimic 2 draw thread experience once did swing + javafx?

no. if could, don't think advisable. such model far easy create subtle, hard debug thread processing related errors. , gain might see such setup may less may wish or expect.

see related articles on why having 2 or more "draw threads" inadvisable:

• threadaches
• multithreaded toolkits: failed dream

java 8 adding experimental command line switch use same thread javafx application thread , swing event dispatch thread. main reason simplifies programming model.

everything fell on javafx , meant lot of pauses when doing things opening filechoosers.

perhaps there inefficiencies in code (such performing i/o on ui thread) caused pauses.

the heavy stuff (e.g. opening filechooser)

opening , rendering filechooser not heavy. javafx can handle such operation without performance degradation. can time consuming stuff related i/o, example walking large file tree recursively file attributes. can in such cases spawn thread i/o run in worker , periodically feed partial results ui thread via platform.runlater. such scheme work well. bottleneck not drawing, having drawing thread provides no advantage. bottleneck slow i/o system , bottleneck mitagated using separate thread i/o main ui thread not impacted , user not experience ui freezes while i/o occurring.