[josm-dev] Painting
Petr Nejedlý
petr at nejedli.cz
Tue Mar 9 20:43:16 GMT 2010
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
More information about the josm-dev
mailing list