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.


Reply via email to