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

Steve Bennett stevagewp at gmail.com
Sat Dec 18 09:06:39 GMT 2010


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



More information about the Potlatch-dev mailing list