You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Somewhere between changing the src and clip region for the next sprite sheet, the previous sprite sheet stays in memory.
Steps to reproduce
No response
Expected Behavior
previous spritesheet/texture is cleared from memory during gc
Actual Behavior
previous spritesheet/texture remains memory after gc
Notes (Optional)
We are building a thumbnail scrubber for media playback. For performance on low-end set-top boxes, we reuse elements that we assign ImageTexture to, avoiding frequent element creation. These elements are rotated to display (depending on the media position):
7 thumbnails on-screen.
6 off-screen thumbnails on either side (3 each side).
Implementation Details:
We use multiple sprite sheets for a single stream.
Each sprite sheet is approximately 4000x336, so clearing these during garbage collection is crucial.
To display the thumbnails, we frequently:
Enable clipping on the texture.
Swap the src of the texture.
Observed Issue:
When swapping the src for the next sprite sheet, the previous sprite sheet occasionally stays in memory. This appears to occur because the activeTextureCount in TextureSource remains >0, even though textures=Set(0).
Debugging Insights:
The problem starts in Texture.removeElement. When entering this function:
The texture’s activeCount is greater than 1.
The element.active is false.
As a result:
The texture and element are removed successfully.
However, the texture’s activeCount is not reduced, leaving it activeTextureCount>0 in TextureSource.
This prevents the texture from being garbage collected.
Workaround:
As a preventative measure we have monkey patched TextureSource.isUsed function to return this._activeTextureCount > 0 && this.textures.size > 0; which works for now.
Assumed cause (Hypothesis):
It may be that this happens if a texture is set on an element that was active, but the element became inactive before the operation completed. The issue is reproducible only with multiple sprite sheets. It happens on all devices, including chrome on Macbook. It is tricky to identify the exact trigger.
The text was updated successfully, but these errors were encountered:
Problem/Opportunity
Somewhere between changing the src and clip region for the next sprite sheet, the previous sprite sheet stays in memory.
Steps to reproduce
No response
Expected Behavior
previous spritesheet/texture is cleared from memory during gc
Actual Behavior
previous spritesheet/texture remains memory after gc
Notes (Optional)
We are building a thumbnail scrubber for media playback. For performance on low-end set-top boxes, we reuse elements that we assign
ImageTexture
to, avoiding frequent element creation. These elements are rotated to display (depending on the media position):Implementation Details:
We use multiple sprite sheets for a single stream.
Each sprite sheet is approximately 4000x336, so clearing these during garbage collection is crucial.
To display the thumbnails, we frequently:
Observed Issue:
When swapping the src for the next sprite sheet, the previous sprite sheet occasionally stays in memory. This appears to occur because the
activeTextureCount
inTextureSource
remains >0, even thoughtextures=Set(0)
.Debugging Insights:
The problem starts in
Texture.removeElement
. When entering this function:activeCount
is greater than 1.element.active
isfalse
.As a result:
activeCount
is not reduced, leaving itactiveTextureCount>0
inTextureSource
.Workaround:
As a preventative measure we have monkey patched
TextureSource.isUsed
function toreturn this._activeTextureCount > 0 && this.textures.size > 0;
which works for now.Assumed cause (Hypothesis):
It may be that this happens if a texture is set on an element that was active, but the element became inactive before the operation completed. The issue is reproducible only with multiple sprite sheets. It happens on all devices, including chrome on Macbook. It is tricky to identify the exact trigger.
The text was updated successfully, but these errors were encountered: