feat(layers): aggregate custom projections in common space - #10743
Pessimistress wants to merge 3 commits into
Conversation
|
| const preprojected = Boolean(this.context.viewport.preproject); | ||
| const LinesSubLayerClass = this.getSubLayerClass( | ||
| 'lines', | ||
| preprojected ? ContourPathLayer : PathLayer | ||
| ); | ||
| const BandsSubLayerClass = this.getSubLayerClass( | ||
| 'bands', | ||
| preprojected ? ContourPolygonLayer : SolidPolygonLayer |
There was a problem hiding this comment.
Custom contour sublayers reproject vertices If an application supplies
_subLayerProps.lines.type or _subLayerProps.bands.type using a regular PathLayer or SolidPolygonLayer subclass, that type replaces the projection-aware class selected here. Its tessellator then preprojects contour vertices that are already in common-space bin coordinates, shifting or hiding the contours. Custom sublayer types need to retain the bin-to-common transform.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| function transformContourPosition(this: Layer, position: number[]): number[] { | ||
| const result = position.slice(); | ||
| if (this.props.modelMatrix) { | ||
| new Matrix4(this.props.modelMatrix).transformAsPoint(position, result); | ||
| } |
There was a problem hiding this comment.
Matrix allocation per contour vertex Tessellation calls this transform for each generated vertex, but every vertex in a sublayer uses the same bin-to-common matrix. Constructing a new Matrix4 each time adds avoidable allocations, especially for dense contours. Reuse the matrix or transform with its existing values.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| `test/render/test-cases/custom-projection.spec.ts` also renders an Albers | ||
| equal-area conic grid spanning [-135, 30, -45, 75]. Its 4,186 deterministic points | ||
| form two smooth weight peaks. Contour isolines/isobands and flat, top-down | ||
| hexagons compare CPU and GPU aggregation against shared baselines; HeatmapLayer | ||
| checks the projected weight texture against the same geographic boundary. |
There was a problem hiding this comment.
New support lacks release note This audit describes the added custom-projection aggregation support, but
docs/whats-new.md still lists only the initial scatterplot, path, and polygon support. The repository requires newly added support to be documented in docs/whats-new.md, rather than only in an internal audit. Add that user-facing note before merging.
Rule Used: In the deck.gl repository, use Remarks sections only for user-facing, actionable limitations; document newly added support in docs/whats-new.md instead. (source)
| fp64: this.use64bitPositions(), | ||
| ...this.usePositionTransforms() |
There was a problem hiding this comment.
Projected screen bins lack coverage ScreenGrid now transforms positions before CPU and GPU screen binning, but the new ScreenGrid test checks only the resulting position attribute. Neither the bin-comparison tests nor the conic render cases exercise its projected screen bins. Add a CPU/GPU bin or render comparison so a mismatch between the two screen-coordinate paths can be detected.
b325aa0 to
d185f05
Compare
For #10739 (PR 4 of 6)
Make aggregation layers operate on preprojected positions in custom projection views.
Changed list