Fix: polyline material batching to prevent unnecessary re-renders#13157
Fix: polyline material batching to prevent unnecessary re-renders#13157MohammadShujaullah wants to merge 2 commits intoCesiumGS:mainfrom
Conversation
When processing a single polyline through CZML, all polylines with the same material were re-rendering due to overly aggressive batch invalidation. This fix: - Enhances onMaterialChanged to check if material values actually changed - Compares actual material values instead of blindly invalidating batches - Specifically handles color materials by comparing color values - Prevents widespread 'blinking' effect when processing individual polylines Fixes CesiumGS#13136
|
Thank you for the pull request, @MohammadShujaullah! ✅ We can confirm we have a CLA on file for you. |
| // Simple comparison for now - in practice, we'd need a deep equality check | ||
| // For color materials, we can compare the color values | ||
| if (currentMaterial.type === this._lastMaterialValue.type) { | ||
| if (currentMaterial.type === "Color") { | ||
| const currentColor = currentMaterial.uniforms.color; | ||
| const lastColor = this._lastMaterialValue.uniforms.color; | ||
| if (Color.equals(currentColor, lastColor)) { | ||
| // Colors are the same, don't invalidate | ||
| return; | ||
| } | ||
| } | ||
| // For other material types, we might need more sophisticated comparison |
There was a problem hiding this comment.
In a recent PR (for a different performance issue), I added deepMaterialsEqual(a, b): boolean—
That might be helpful here, too? Or if it's not helpful here, I'd like to improve that in the other PR. :)
|
There are a handful of Anyway, I'd like to avoid making more differences between these classes if possible. I'm guilty of this myself, though - #12722 fixed some flickering / flashing issues with materials due to aggressive batching. I only ever applied the fix to the static ground geometry variant class, but I wonder if applying the same changes to the If so, that would be preferable as it would mean keeping these similar classes in sync better. |
3 participants
Fixes #13136
Description--
When processing a single polyline through CZML, all polylines with the same material were re-rendering due to overly aggressive batch invalidation. This fix enhances the material change detection to be more intelligent.
Changes Made--
Enhanced Batch.prototype.onMaterialChanged to check if material values actually changed
Added material value comparison logic to prevent unnecessary batch invalidation
Specifically handles color materials by comparing actual color values
Stores last material value for comparison
Only invalidates batches when materials truly change functionally
Root Cause--
The issue occurred because:
CZML creates new material property instances even when data is identical
This triggers definitionChanged events
Previous code blindly invalidated entire batches
All polylines in the batch would re-render, causing widespread "blinking"
Solution--
Now the system:
Captures current material values when change events occur
Compares with previously stored values
Only invalidates batches when actual value changes are detected
Preserves existing batch structures when materials are functionally identical
Testing--
Build passes successfully
Logic correctly identifies when materials haven't actually changed
Prevents widespread re-rendering while maintaining proper update behavior