-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panning the map is jaggy and slow. #1727
Comments
Hmm, that's definitely well below the level of performance we expect, and most people see, on an i7, especially with Chrome. Can you try a couple of diagnostics?
|
URL: http://www.openstreetmap.org/edit?editor=id#map=18/56.83258/24.51959 Graphics Feature Status |
Is there a copy of non-obfuscated ID I could debug? |
Another bad behavior (easier to test): Still win8, core i7, using mouse. |
Sure, clone the repository and open index.html |
@viesturz any further profiling data you can share? |
Finally got some time to play with this. #1 Zoom out a bit and move map to a new location, map data loads incrementally in chinks over several seconds. Map freezes whenever data is received. Here is a Chrome "Flame Chart" on a typical load event, totaling 250 ms. Observations:
#2: start drawing a line with 1 segment and move mouse around so the segment moves with it. I see 30/30% distribution between browser rendering SVG and javascript. It's really wrong and should be more like 30/1 %. There is too much computation going on just to move a single point on screen (or even replace the whole line). Viesturs |
We've considered using web workers; the blocking factor is the fact that the DOM APIs used to parse the OSM API XML response are not available in web workers, and the OSM API does not yet support JSON.
It's actually an incremental redraw -- the
We've spent some time optimizing tagClasses in the past; it's not currently looking like a bottleneck in my profiles (<1% total time).
True, though it wouldn't reduce the overall time, just spread it out over more turns of the event loop.
The resulting path is cached and used several times over the course of rendering -- it's work that has to be done at some point. That said, since we're not currently using any advanced d3.geo.path features like resampling or clipping, we might save a few % by iterating nodes directly rather than going through asGeoJSON + d3.geo.path. Though asGeoJSON is now cached, so that part will only be a win on initial draw.
I'd love to get there, but I think you're underestimating the amount of processing that iD does to support interactions like fading labels in and out, showing and hiding vertices on hovered ways, etc. |
Would it help if the |
Definitely. With JSON it might not even be necessary or beneficial to use a web worker. |
Closing here. Path calculation was optimized in 1.3, other avenues covered by #1498. |
Steps to reproduce:
A quick profile shows this is mostly due to SVG updates being slow.
Have you considered using canvas instead? Kinect.JS?
Tested on: chrome, firefox, win8, x64.
The text was updated successfully, but these errors were encountered: