-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Map debug options in release mode #5699
Comments
We could log a message to warn the user that this doesn't do anything to avoid confusion. |
These are public APIs in the iOS and macOS SDKs, documented as aids for debugging styles. We'll need to update the documentation to note that they're no longer functional, are deprecated, and exist only for backwards compatibility. |
Per conversation with @1ec5 - it turns out that the tile boundary and tile info debug flags are currently being very useful for bug reporting. It seems reasonable then to make |
They're already public, and I don't think it's worth breaking backwards compatibility over these flags, so we'd mark them as deprecated and document them as nonfunctional for now. |
These are all currently exposed in the Node.js bindings as well, and we've used them a little for debugging, but they're not clearly documented anywhere AFAIK. |
I believe we have general consensus to make both |
We use map debug options mainly as a mechanism to inspect our rendering engine. This usually comes with additional overheads that potentially affects metrics like binary size and memory footprint - see #5555 as example. In light of this, I see two possibilities in which we could avoid exposing this in release mode:
MapDebugOptions
no-ops in release mode - this way we'd still have functions likeMap::setDebug
available in release mode to avoid any binary incompatibility, but their internal implementation would provoke no effects in the engine.MapDebugOptions
,Map::setDebug
and related public API functions in release mode - this adds extra complexity for platform-specific code that would also need to remove their related functions in release mode.I'm inclined to accept the former option due to its low complexity and maintenance - however I'd love to read your thoughts before proceeding with this.
@mapbox/gl
The text was updated successfully, but these errors were encountered: