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.
Chris
