Investigate GPU-process memory usage when displaying edges
- Dominant language
- JavaScript
- Stars
- 15.7k
- Forks
- 3.9k
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 34
Description
### What happened?
Not sure this is a bug. This issue is about investigating the memory usage when edges are displayed in CesiumJS, determining if anything can be done to further reduce memory. This usage has always been the case.
Displaying `EXT_mesh_primitive_edge_visibility` edges produces a large increase in Chromium GPU-process resident memory in our benchmark for a representative AEC dataset:
| Configuration | Peak GPU-process RSS |
|---|---:|
| No edge extension | ~245 MB |
| Edge extension, edges hidden with lazy loading | ~246 MB |
| Edge extension, edges displayed | ~1244 MB |
Measured on an Apple M4 Max using Chromium/ANGLE Metal and a minified CesiumJS build containing #13785 and #13789. Three runs per configuration, first run discarded.
RSS is Resident Set Size, not a direct VRAM measurement. The ~1 GB increase needs attribution before assuming it is all live edge-buffer data.
### Reproduction steps
1. Use a CesiumJS build containing #13785 and #13789.
2. Load an edge-bearing tileset with `edgeDisplayMode: Cesium.EdgeDisplayMode.SURFACES_ONLY`. Do not call `scene.snap()`.
3. Move to a detailed view, wait for tiles to finish loading, and record Chromium’s GPU-process RSS.
4. Start a fresh browser session and load the same tileset with `edgeDisplayMode: Cesium.EdgeDisplayMode.SURFACES_AND_EDGES`.
5. Use the same camera position and viewport, wait for loading to finish, and record GPU-process RSS again.
### Sandcastle example
_No response_
### Environment
Browser: Chromium
CesiumJS Version: Latest (main)
Operating System: macOS and others
### AI acknowledgment
- [x] I used AI to generate this issue report.
- [x] (If the above is checked) I have reviewed the AI-generated content before submitting.
Contributor guide
Research direction
Start by reproducing the two edgeDisplayMode configurations in a CesiumJS build containing #13785 and #13789, using the stated camera and Chromium GPU-process RSS measurements. Compare the loading and displayed-edge paths, including the effect of not calling scene.snap(); done means attributing the memory increase and documenting or implementing a justified reduction if possible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- computer-graphics, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100