[josm-dev] Painting

[Petr Nejedlý]

Jiri Klement wrote:
> One of the reason why painting appears slow is the fact that it's done
> in EDT thread. I think there should be special thread for painting.
>   
Disagreed (with both sentences).
> EDT will only send request to repaint and copy offscreen buffer to
> screen when it's ready. Painting thread will wait for repaint
> requests. When request arrives it will start painting immediately. If
> another request arrives during painting, it will wait. If there are
> multiple repaint request after painting is finished, only the last one
> will be processed.
>   
This is exactly what RepaintManager in Java does for you.
User events (mouse gestures, ...) and posted tasks are processed
and the repaint requests they caused are buffered and a repaint request
is posted at the end of the event queue. Once the queue drains, the repaint
happens, only once.

If you think of coleascing paints across more user gestures (like 
continuous dragging),
you'll face two problems:
1) the trade-off between UI responsivity and the amount of coalesced 
events. Too short delay
  before painting and you paint on every event anyway. Too long delay 
and the UI will feel slow
  most of the time.
2) Loss of feedback in the cases where the painting already takes 
considerable amount of time.

Separate thread won't help you neither on multicores, as you'll keep the 
problem serialized. Everything
else but painting is fast enough, so you'll have AWT thread idle happily 
waiting for next event while the
painting thread will fully load one core. Well, there will be the 
benefit of having the rest of the UI responsive,
but we're not here to solve multisecond painting of zoom-to-fit of large 
datasets this time, are we?

As for the initial comment regarding full repaint just to do rubber-band:
There's no problem with full repaint as long as you do it fast enough. 
And this is doable. Proved.

Moreover, I fear the increased code complexity necessary for partial, 
maybe filtered, repaints
may slow down the general painting so the net result will be worse.

 
For the record, I've tried current JOSM and must say that the rendering 
speed improved a lot.
What might help, IMO, is to disable painting plain points over given 
zoom level.
JOSM already paints large datasets when zoomed in and slight 
simplification, when zoomed out
can only improve the situation. (You don't need to see individual nodes 
when looking at half the
Germany, do you?)


Regards,
Nenik