[josm-dev] Presentation data layer?
Frederik Ramm
frederik at remote.org
Fri Oct 19 22:54:11 BST 2007
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
More information about the josm-dev
mailing list