Improve rendering performance of symbols with symbol-sort-key #9751
Conversation
src/render/draw_symbol.js
Outdated
| @@ -236,7 +236,12 @@ function drawLayerSymbols(painter, sourceCache, layer, coords, isText, translate | |||
| // Unpitched point labels need to have their rotation applied after projection | |||
| const rotateInShader = rotateWithMap && !pitchWithMap && !alongLine; | |||
|
|
|||
| const sortFeaturesByKey = layer.layout.get('symbol-sort-key').constantOr(1) !== undefined; | |||
| const canOverlap = layer.layout.get('icon-ignore-placement') || | |||
There was a problem hiding this comment.
This should probably be refactored into a separate function, but I'm not sure about the best place for it
There was a problem hiding this comment.
I think we should try add this to SymbolBucket's constructor to avoid the overhead of retrieving this value for every feature while it's guaranteed to be the same, and because there's already similar set up happening there (this.sortFeaturesByKey). In fact a very similar logic is already present there for sortFeaturesByY.
There was a problem hiding this comment.
Nice! I made canOverlap a field in SymbolBucket, and used it to calculate sortFeaturesByY as well.
|
cc @pozdnyakov |
|
@mourner can you review this since Mikko is out of office for a bit? |
src/render/draw_symbol.js
Outdated
| @@ -236,7 +236,12 @@ function drawLayerSymbols(painter, sourceCache, layer, coords, isText, translate | |||
| // Unpitched point labels need to have their rotation applied after projection | |||
| const rotateInShader = rotateWithMap && !pitchWithMap && !alongLine; | |||
|
|
|||
| const sortFeaturesByKey = layer.layout.get('symbol-sort-key').constantOr(1) !== undefined; | |||
| const canOverlap = layer.layout.get('icon-ignore-placement') || | |||
There was a problem hiding this comment.
I think we should try add this to SymbolBucket's constructor to avoid the overhead of retrieving this value for every feature while it's guaranteed to be the same, and because there's already similar set up happening there (this.sortFeaturesByKey). In fact a very similar logic is already present there for sortFeaturesByY.
| @@ -333,7 +334,8 @@ function drawLayerSymbols(painter, sourceCache, layer, coords, isText, translate | |||
| hasHalo | |||
| }; | |||
|
|
|||
| if (sortFeaturesByKey) { | |||
| if (hasSortKey && bucket.canOverlap) { | |||
| sortFeaturesByKey = true; | |||
There was a problem hiding this comment.
I'm just not sure about this particular bit — we need sortFeaturesByKey after this loop, so I had to assign it like this.
src/data/bucket/symbol_bucket.js
Outdated
| @@ -609,6 +614,7 @@ class SymbolBucket implements Bucket { | |||
| lineOffset: [number, number], | |||
| alongLine: boolean, | |||
| feature: SymbolFeature, | |||
| layer: SymbolStyleLayer, | |||
There was a problem hiding this comment.
layer is no longer used, so this is a leftover right?
There was a problem hiding this comment.
Oh, didn't catch that! Fixed 🙂
| @@ -333,7 +334,8 @@ function drawLayerSymbols(painter, sourceCache, layer, coords, isText, translate | |||
| hasHalo | |||
| }; | |||
|
|
|||
| if (sortFeaturesByKey) { | |||
| if (hasSortKey && bucket.canOverlap) { | |||
| sortFeaturesByKey = true; | |||
src/symbol/symbol_layout.js
Outdated
| @@ -665,6 +667,7 @@ function addSymbol(bucket: SymbolBucket, | |||
| iconOffset, | |||
| iconAlongLine, | |||
| feature, | |||
| layer, | |||
|
Thank you! |
Pull request #7678 introduced sorting of symbol features across tiles. Unfortunately, this kind of sorting requires that symbols with distinct values of sort key are rendered in separate draw calls.
This can be a huge performance hit for a large number of labels, especially if
symbol-sort-keyis data driven (e. g. if we want to prioritize city labels by population). In such a case pretty much every label will end up in a separate draw call, which can result in hundreds of extra draw calls.However, this sorting is only required if symbols of the current layer can overlap (i. e. when one of the
*-allow-overlapor*-ignore-placementprops is true). Otherwise, the rendering order is not important. This pull requests adds a check for this. If it detects that labels of the current layer cannot overlap, it puts all of them in one segment as before (and they get rendered in one draw call).This only affects rendering order and should not affect prioritization during placement at all.
Launch Checklist