[memory]: test memory leaks in canvas operations #5314
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Technical Documentation: Memory Usage in Canvas operations (sp-color-area)
Overview
The
ColorAreacomponent is a memory-intensive component due to its canvas-based operations and color manipulation functionality. This document explains why certain memory usage is expected and cannot be fully eliminated, as well as why the current memory testing approach is appropriate.Memory Usage Analysis
Expected Memory Footprint
The
ColorAreacomponent has a baseline memory footprint of approximately 12KB, which is primarily composed of:Component Structure: ~2-3KB
ColorController,LanguageResolutionController)Canvas Operations: ~4-5KB
Event Handling: ~2-3KB
DOM References: ~1-2KB
Why Canvas Operations Are Memory-Intensive?
Canvas-based rendering requires additional memory because:
ResizeObserverensures proper layout adjustments.Memory Testing Approach used in SWC
Our
testForMemoryLeaksfunction focuses on detecting memory leaks, not enforcing a strict memory limit. It:Why Canvas Operations like
sp-color-areaAre Excluded from Memory Testing?Canvas-based components naturally use more memory. 12KB is reasonable given that
ColorAreaperforms:For context:
Is 12KB a Problem?
12KB of memory usage is not necessarily a problem, especially for a component that:
For comparison:
Conclusion
The
ColorAreacomponent’s memory footprint is expected due to its complexity. While it cannot be fully reduced, our memory testing approach effectively prevents leaks by ensuring stable memory usage over time. Proper cleanup indisconnectedCallbackguarantees that resources are released, maintaining performance and reliability.