-
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
rendering performance brainstorming #1498
Comments
I noticed you (d3) are clipping all paths to visible extent. Is this necesary? The browser graphics engine does the clipping much more efficently. Also you would not need to re-render the objects after pan. Starting to guess here, but are you re-projecting points to screen on every pan? |
Currently the paths for line geometries are manually clipped, but areas are not. We actually found that manual clipping was significantly faster than SVG clipping, as it means that you can completely drop the SVG elements for vertices outside the viewport. iD does re-project and re-render at the end of each pan -- avoiding that is what the third bullet point above is about. |
A lot has moved on performance in the last 3 years, and I've done a bunch of performance profiling to prepare for the iD v2 launch, so I'm going to close this and open a new performance ticket. to summarize:
d3.geo has some optimizations in d3 v4 (elimination of extra steps and memory copies)
Path calculation is pretty fast on modern hardware.. The bigger bottlenecks that I see are in osm tile parsing (which can be moved to a web worker) and background imagery polygon testing (a preliminary rbush test before the slower polygon test can speed that up significantly).
Still a good idea.. We could do extent renders of the newly visible regions. |
This is what rendering DC at z16 looks like:
(Flame Chart profile in Chrome Canary is awesome.)
Rendering areas dominates, followed by labels, then lines. Points and vertices are not significant contributors.
The one thing that sticks out (orange rectangles) is streaming geometry through d3.geo.path() in order to calculate areas and generate SVG path strings. This is hard to cache because it depends on the current projection scale and translation.
Options:
Of those options, the third is looking the most attractive to me right now. Anyone got any other ideas to throw in?
The text was updated successfully, but these errors were encountered: