[Potlatch-dev] Speeding up WayUI.setHighlightOnNodes()

[Steve Bennett]

Ok, well in the end I did this fairly simply, with a few extra tests
in setHighlightOnNodes() and an extra call back from
UpdateEntityUIs(). I think I missed a much simpler way somewhere.

Also, I'm still a bit confused about when exactly NodeUIs get
allocated for nodes that are part of ways and don't have tags. The
code uses the term "poi" in some places to mean only nodes with tags
(I think), but in other places it means all nodes, like
Connection.getObjectsByBbox() (again, I think).

Anyway - the code is faster now, with no known bugs/side-effects. :)

Steve

On Sat, Dec 18, 2010 at 8:06 PM, Steve Bennett <stevagewp at gmail.com> wrote:
> Hi all,
>  I'm working on this speed up, would welcome any insights or
> suggested solutions. Or maybe just writing out what my thinking so far
> will give me the solution :) (Yes, this is a fairly minor issue, but I
> have to start somewhere.)
>
> I started with the basic problem of "why is it so slow when, in the
> middle of drawing a way, the mouse crosses over a long way?" It turns
> out it's because setHighlightOnNodes() is incredbly slow: for every
> point along the way, it has to allocate a NodeUI, then set its "hover"
> property, then render it, even if it's nowhere near the visible
> screen. Then as soon as the mouse cursor slips off it, it has to do
> the same thing to unhighlight it. On my machine, with some bigger ways
> (coastlines, administrative boundaries) this can take something like
> half a second each time around. If you're trying to draw a river which
> follows an administrative boundary, it's a painful experience. (On a
> side note, I'd like to add a feature to allow you to hold down a key,
> maybe alt, which will prevent looking for junctions.)
>
> So, first solution was to add a test in WayUI.setHighlightOnNodes() to
> only actually do the highlight if the node is on screen. That made it
> much faster, but introduced a bug: if the map moves, highlighted nodes
> get left behind (because when the un-highlight code is called, it's
> the same routine, only a different bunch of nodes get hit). This is
> particularly bad if you've selected the way, rather than just hovered
> over it.
>
> Looking a bit deeper, it seems the problem arises specifically because
> there's a (mostly reasonable) assumption that an object is either on
> screen or off screen, and if it's partially on screen, you can treat
> it as full on screen with little penalty. We might need to change that
> assumption and add special behaviour for long ways. It doesn't seem
> too costly to create the WayUI, including the offscreen bit, but we
> shouldn't create offscreen NodeUIs. I'm just not sure how big to make
> this fix: just a quick hack to solve this particular usability issue,
> or try and solve a bigger problem.
>
> So, I'm thinking:
> 1) add a field to WayUI (or Way, not sure) so that the way knows that
> it is in the "nodes highlighted" state. (Currently I don't think
> there's any state stored other than that of the individual nodes)
> 2) add some logic to MapPaint.updateEntityUIs to give Ways/WayUIs the
> opportunity to remove offscreen NodeUIs and add freshly onscreen
> NodeUIs
>
> A totally different approach would be for a highlighted way to add an
> event listener for MapEvent.MOVE, and use that opportunity to update
> its NodeUIs.
>
> I'm thinking the former approach though, as it seems more generic, and
> it's fairly plausible that the situation with offscreen NodeUIs will
> arise in circumstances other than just node highlighting.
>
> Thoughts? Comments? Am I on the right track? Horribly mistaken?
>
> Steve
>