[josm-dev] Selection Performance

[Karl Guggisberg]

> So I would go even further and deprecate/remove the selection notion from the primitive altogether. It is used in few places only anyway (beyond painting) and would be well served by a selection set on the Layer anyway.

I support that.

-- Karl 

-----Ursprüngliche Nachricht-----
Von: Petr Nejedlý [mailto:petr at nejedli.cz] 
Gesendet: Donnerstag, 8. Oktober 2009 22:55
An: karl.guggisberg at guggis.ch
Cc: 'Dave Hansen'; 'josm-dev'
Betreff: Re: AW: [josm-dev] Selection Performance

Dave Hansen napsal(a):
 > On Thu, 2009-10-08 at 10:18 +0200, Petr Nejedlý wrote:
 >> First and foremost, selection status is not a property of the data.
 >> Changing the data set just because the user have selected something is  >> plain wrong. Having a per-dataset selection is quite disturbing too -  >> there should be only one, system-wide.
 >
 > OK, so you're saying that because selecting things is not a property of  > the data that it shouldn't be a part of the data set?  Uh, ok.  Aren't  > ways and nodes part of the data set?  Check out  > OsmPrimitive.setSelected().  Sure seems to *ME* like selections are part  > of the data set.
Selections are currently part of the OSMPrimitive API, sure.
What I'm saying is that it doesn't belong there.
In the worst case, it may be the property of the DataSet, but...

Karl Guggisberg napsal(a):
>> Do you have a better suggestion on where to stick the "selection cache"
>> or whatever we want to call it than in the DataSet?
> I think the "selection cache" (a collection of the currently selected
> primitives) should be maintained for each data layer (either by the 
> layer or by some global selection cache which keeps a selection state 
> per layer). If the dataset wasn't attached to a data layer why would 
> you want to select/unselect objects? What I never liked is that there 
> is a boolean field 'selected' on OsmPrimitive - this looks weired.

... exactly! Layer is the view of the DataSet. No view, no selection.
Several views of the same dataset -> maybe several different selections.
Asking a primitive whether is it selected or not is a strange concept anyway. Why should it know? In which context?
Imagine a "tactical overview" (a small view of the complete in-memory data rendered in the screen corner) or any other auxiliary view of the same dataset. You'd like to use the same rendering code, yet you don't want it to render the selected primitives the same way, for example.

So I would go even further and deprecate/remove the selection notion from the primitive altogether. It is used in few places only anyway (beyond painting) and would be well served by a selection set on the Layer anyway.

Regards,
   Nenik

PS: In case you are afraid of the memory footprint of the selection set, you can borrow the Storage class from josm-ng. It will cost around 7B per selected entry (that is pretty small unless you select everything) depending on the target load factor and allow you to remove a boolean from OsmPrimitive (costing anything between 0 and 4 bytes per OsmPrimitive in memory, depending on several factors). Many more places in JOSM would benefit from Storage anyway (String cache in OsmReader,
Long->OsmPrimitive maps in the OsmReader and the MergeVisitor, ...)