[josm-dev] Presentation data layer?

[Frederik Ramm]

Hi,

    I wonder whether we need something that I'll call a "presentation 
data layer" in JOSM. (This is an internal technical issue and will not 
change the user perspective, except from maybe making JOSM faster.)

Currently, every time JOSM redraws the screen, it goes through all the 
loaded objects and paints them. It really goes to the raw nodes and ways 
each time - with a few minor exceptions:

* node coordinates are not transformed each time; the transformed 
coordiates are computed once and then stored with the node.

* the same goes for the "tagged" property; computing this from the list 
of tags would be an expensive process so it is computed once and then 
just used.

I could imagine an number of other things that we might store to make 
drawing faster. For example, Ulf has suggested to store the result of 
the "is an area" test that Mappaint performs on each way. I think it 
might be worthwhile to store a rectangular bounding box with each way 
(maybe even together with some sort of quadtile index) to quicken the 
"which objects are at the current position" lookup that will become more 
important if we want to further smarten the editing process by providing 
a "what will happen" highlight.

I wonder if we should perhaps introduce a set of "presentation" objects 
that serve as interfaces between the data layer and the drawing, so that 
the "way presentation object" would contain the bounding box, "tagged" 
property, and all other derived stuff, plus a reference to the original 
way. And the same for nodes of course. The drawing code would normally 
just look at the presentation object and find everything it needs there 
in ready-to-use form, without having to recurse to the raw object to 
find out how it should be drawn.

This would make JOSM more complex as the presentation objects would have 
to be kept up to date all the time, but on the other hand it might make 
the whole drawing process cleaner.

If anyone has anything to say about this or maybe has some common 
practice/design pattern to offer, please shout.

Bye
Frederik