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 _______________________________________________ Potlatch-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/potlatch-dev
