Drawing using multiple threads in Swing & EDT - Can JavaFX support this?

Chris Gay chris.gay5000 at gmail.com
Sun Apr 27 09:40:25 UTC 2014

With Swing and EDT you can use multiple drawing threads.

Context: Interactive Floating Point Vector Graphics

I use the fairly standard technique of having an Off-Screen Sliding Buffer, and a Thread dedicated to drawing just the Display List. For each re-draw, it obtains a new Graphics Context from the Off-Screen Buffer, draws everything to it, then draws all artefacts representing rubber-banding or XOR Mode drawn effects with a separate XOR Mode Graphics Context. For live rubber-banding, it simply gets a XOR Mode Graphics Context, re-draws what you want to Erase, and then draws the new effects, and without having to re-draw the Display List. Once drawn, it zaps it to the Window using a fast BitBlt on the Swing Event Thread. The Screen Buffer is larger than the Window, so that live (auto) scrolling small distances does not require a re-draw, only a BitBlt. In addition, when zooming in and out, I first do a scaled BitBlt to the window, to give immediate feedback to the user, which precedes the slower complete re-draw of the Display List at a new scale, followed by another BitBlt. All BitBlt'ing in done on the Event Thread.

Every mouse event may change the state of the Display List, using the Event Thread, and that simply requests a re-draw. Hitting events from the Event Thread scan the Display List from front (nearest viewer = end of list) to rear (furthest from viewer = start of list), whereas drawing works in the opposite direction, so the 2 threads only pass one another once, but it does require synchronization. For events that lead to much slower computational actions, these are passed to a third thread for action, and can correctly update the Display List since access to it is synchronised, and when finished, can inform the Event Thread.

The only downside, given that my code supports zooming, is that you cannot use Bit-Maps for small artefacts such as handles. Instead, everything has to be drawn using floating point vector graphics. Having said that, even in Java 6 on older hardware, and using 64 bit precision vectors, (Swing converts them to 32 bit for rendering), it is pretty nippy, but it is unlikely to get much acceleration from a GPU. One of the speed killers is dotted or dashed lines for XOR Mode use. I use 0 (i.e. 1) pixel width, and longish dashes, for speed, and hollow handles have solid 0 (i.e. 1) pixel outlines.

This approach keeps the UI highly responsive, as it is a highly user-interactive system. However, I've never seen the approach documented by authors, and I had to develop it from first principles, even though it is fairly obvious that commercial products use it. It is easy to describe it, as above, but gets very complex to implement, which is why authors and training books avoid teaching it.

I haven't seen any examples of the approach published for Android either.

It also goes against the MVC philosophy. As an engineer, my objects are physical entities that know their own properties. Stylesheets, as such, suit a different world, where data and appearance are de-coupled.

I do not know if JavaFX was ever designed to allow such an approach.


More information about the openjfx-dev mailing list