-
Notifications
You must be signed in to change notification settings - Fork 1.3k
proposal: shape layer grouping API #1708
Comments
If we are liking the looks of this, we should mock out what this Cocoa API looks like exactly, including styling configuration, how it interacts (if at all) with eventual layer reordering, and removal/other management. |
Sure, why not? |
Only because it's unlike Apple's API and may raise questions as to when or when not to use it. The answer to that is:
|
Sounds like the performance gains would be worth the divergence/complexity. Having a built-in construct for managing groups of annotations is also a friendly addition in general. Would this also carry over into marker annotations? If so, we should be careful not to make this layer grouping too easily confused with our eventual support for clustering. |
This optimization is not needed for lines. LineBucket in gl-native is actually a MultiLine. |
I think it might be worth waiting until data driven styling is implemented before worrying about this. Data driven styling will change the way this problem looks. I don't think the first implementation of shapes needs to be able to support thousands or even hundreds of shapes. |
+1 to what @ansis said. With data driven styles we will have more optimization options for transparently combining multiple layers into one draw call. |
Working towards #837 instead. |
If we proceed with this, it will also happen on Android.
Per voice with @kkaefer, our shape annotation implementation in #1655 could be improved by creating a layer grouping API identically-styled shapes.
Currently, each shape annotation gets its own style layer for reasons of:
insertOverlay:aboveOverlay:
.However, performance is a concern here. Adding 10,000 similarly-styled shapes means 10,000 more style layers, which means 10,000 more GL draw calls. 🚨 NOT TENABLE 🚨
If we introduced the concept of a shape group for identically-styled shapes, a consumer could add 10,000 blue polylines to the map and incur 1 style layer and 1 draw call.
Instead of:
It would look something like:
This would also allow functionality like:
We would still support
mapView.addAnnotation(polyline)
like MapKit, with the understanding that it's more efficient to add many shapes with the groups API instead.Thoughts @1ec5 @friedbunny?
The text was updated successfully, but these errors were encountered: