Motivation
Currently the raster_source tileProvider callback (or custom tile loading logic for raster sources) executes on the main thread. This prevents using Worker-only capabilities for raster tile processing and can cause main-thread work and jank when loading or decoding many tiles. Enabling tileProvider logic to run in a Worker would reduce main-thread contention and improve responsiveness for applications that load or preprocess many raster tiles.
Design Alternatives
- Do nothing: keep the current behavior where tileProvider runs on the main thread. This preserves existing semantics but continues to limit Worker-based processing and may cause main-thread jank for heavy workloads.
- Add an opt-in mechanism that allows tileProvider logic to run in a Worker context. This approach preserves backward compatibility while enabling heavier preprocessing to be offloaded from the main thread.
Design
The proposed design is to introduce a feature that allows raster_source tileProvider to run in a Worker context when explicitly enabled by the application. The feature should be opt-in so existing integrations continue to run unchanged.
Advantages
- Reduces main-thread work and associated UI jank for raster-heavy workflows.
- Enables applications to leverage Worker-only processing strategies for raster tiles.
Potential drawbacks
- Additional complexity in the tile loading pipeline and cross-thread coordination.
- Potential edge cases around transferable data, decoding formats, and integration with the renderer that will need careful handling.
Mock-Up
A feature request rather than a finished UX; no UI mock-up required. The issue should document the desired behavior and expected developer ergonomics for opting into Worker execution.
Concepts
Introduce a clear opt-in contract for raster tile providers to indicate they may run in a Worker. The contract should define the expected inputs (tile coordinates, URL/metadata) and the expected shape of the returned tile data so the map runtime can integrate processed tiles into the renderer.
Implementation
At a high level, the implementation would require extending the raster tile loading pipeline to support invoking tileProvider logic in a Worker when enabled, and a mechanism for delivering the processed tile data back to the map runtime for rendering. The implementation must preserve backward compatibility for existing tileProvider callbacks and handle cross-thread coordination and error cases.
Motivation
Currently the raster_source tileProvider callback (or custom tile loading logic for raster sources) executes on the main thread. This prevents using Worker-only capabilities for raster tile processing and can cause main-thread work and jank when loading or decoding many tiles. Enabling tileProvider logic to run in a Worker would reduce main-thread contention and improve responsiveness for applications that load or preprocess many raster tiles.
Design Alternatives
Design
The proposed design is to introduce a feature that allows raster_source tileProvider to run in a Worker context when explicitly enabled by the application. The feature should be opt-in so existing integrations continue to run unchanged.
Advantages
Potential drawbacks
Mock-Up
A feature request rather than a finished UX; no UI mock-up required. The issue should document the desired behavior and expected developer ergonomics for opting into Worker execution.
Concepts
Introduce a clear opt-in contract for raster tile providers to indicate they may run in a Worker. The contract should define the expected inputs (tile coordinates, URL/metadata) and the expected shape of the returned tile data so the map runtime can integrate processed tiles into the renderer.
Implementation
At a high level, the implementation would require extending the raster tile loading pipeline to support invoking tileProvider logic in a Worker when enabled, and a mechanism for delivering the processed tile data back to the map runtime for rendering. The implementation must preserve backward compatibility for existing tileProvider callbacks and handle cross-thread coordination and error cases.