You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Digging into rendering performance, I discovered that #2938 regressed it more severely than was demonstrated by the benchmarks, which averages frame duration with too many "easy" zooms.
With a simple isolated benchmark that renders a 1440x900 map of Mapbox Streets on z13 (the most detailed one) in DC, CPU duration of a frame is almost 2 times bigger in v0.23 compared to v0.22.
This leads to a huge increase in dropped frames when panning and zooming, especially for full-screen maps of cities. The effect should also be much more pronounced on weaker machines (I'm testing on my MBP).
Other DDS PRs regress performance too, but to a lesser extent because CPU performance is line-dominated according to the Chrome profiler.
I think that we need to prioritize addressing this technical debt now, before it grows out of control with more DDS properties support.
There are several things that seem to be contributing to the regression:
bucket.setUniforms does a full recalculation of DDS-enabled properties (getPaintValue), even though they don't differ from values in layer.paint (that are recalculated on every frame too). Replacing uniform.getValue(...) with layer.paint[uniform.paintProperty] generally works, with a few glitches to fix (fallback values like fill-outline-color falling back to fill-color are not calculated during the main style recalculation phase).
The big block of uniform sets and useProgram in draw_line that come before painter.enableTileClippingMask(coord); now execute individually for each tile instead of once for a layer, although in non-DDS case the program options are the same (and maybe in case of DDS as well — I'm not sure). We need to refactor this code so that it is back to being executed once per-layer.
@lucaswoj I'll need your help to tackle this as I don't fully understand all the quirks of DDS code/vision yet, but I'm sure we can go back to v0.22 performance for Mapbox styles while keeping the DDS features.
cc @jfirebaugh@mollymerp
The text was updated successfully, but these errors were encountered:
On the first point, it sounds like we need to bite off #3044 and refactor so that we have a single canonical representation of paint values that can be updated once per frame (or less if possible) and then shared by bucket.setUniforms and others.
refactor so that we have a single canonical representation of paint values that can be updated once per frame (or less if possible)
@jfirebaugh I made such a refactor before DDS — it's intended to be canonical and calculated once per frame max; just need to fix the new DDS code to conform to this intention.
mapbox-gl-js version: v0.23+
Digging into rendering performance, I discovered that #2938 regressed it more severely than was demonstrated by the benchmarks, which averages frame duration with too many "easy" zooms.
With a simple isolated benchmark that renders a 1440x900 map of Mapbox Streets on z13 (the most detailed one) in DC, CPU duration of a frame is almost 2 times bigger in v0.23 compared to v0.22.
This leads to a huge increase in dropped frames when panning and zooming, especially for full-screen maps of cities. The effect should also be much more pronounced on weaker machines (I'm testing on my MBP).
Other DDS PRs regress performance too, but to a lesser extent because CPU performance is line-dominated according to the Chrome profiler.
I think that we need to prioritize addressing this technical debt now, before it grows out of control with more DDS properties support.
There are several things that seem to be contributing to the regression:
bucket.setUniforms
does a full recalculation of DDS-enabled properties (getPaintValue
), even though they don't differ from values inlayer.paint
(that are recalculated on every frame too). Replacinguniform.getValue(...)
withlayer.paint[uniform.paintProperty]
generally works, with a few glitches to fix (fallback values likefill-outline-color
falling back tofill-color
are not calculated during the main style recalculation phase).useProgram
indraw_line
that come beforepainter.enableTileClippingMask(coord);
now execute individually for each tile instead of once for a layer, although in non-DDS case the program options are the same (and maybe in case of DDS as well — I'm not sure). We need to refactor this code so that it is back to being executed once per-layer.@lucaswoj I'll need your help to tackle this as I don't fully understand all the quirks of DDS code/vision yet, but I'm sure we can go back to v0.22 performance for Mapbox styles while keeping the DDS features.
cc @jfirebaugh @mollymerp
The text was updated successfully, but these errors were encountered: