Description
lHi team,
I hit an error inside luma.gl while debugging a Deck-based map application.
The exception stops in CanvasContext.getMaxDrawingBufferSize when reading:
this.device.limits.maxTextureDimension2D
From debugging, this is happening inside luma.gl rather than in my own app code.
Observed behavior
During resize / destroy / view transition related flow, CanvasContext.getMaxDrawingBufferSize can be called when device is not in a valid state anymore, and the method still directly reads device.limits.maxTextureDimension2D.
This appears to cause an exception when device is undefined, partially initialized, or otherwise invalid during that lifecycle window.
Expected behavior
CanvasContext.getMaxDrawingBufferSize should guard against an invalid or unavailable device state and either:
return a safe fallback size, or
skip the resize-related path gracefully
Environment
@deck.gl/core: 9.2.6
@luma.gl/core: 9.2.6
@luma.gl/engine: 9.2.6
Vite dev environment
Browser: Chrome
OS: macOS
Where it stops
CanvasContext.getMaxDrawingBufferSize
reading:
this.device.limits.maxTextureDimension2D
Why I think this is in luma.gl
I paused on the thrown exception in DevTools and the breakpoint landed in luma.gl source rather than my own wrapper code. The stack points into the canvas context resize / drawing buffer size path.
Potential fix direction
It may be enough to add a lifecycle guard before reading device.limits, for example handling cases where:
this.device is missing
this.device.limits is missing
the context is already destroyed / tearing down
If useful, I can also provide:
full call stack
screenshot from DevTools
a reduced repro if I can isolate it further
Thanks.
Flavors
Expected Behavior
No response
Steps to Reproduce
Possible patch idea
check whether this.device and this.device.limits are available before reading maxTextureDimension2D
if not available, fall back to current drawing buffer size or another existing safe fallback
optionally skip resize handling when context is already destroyed
Environment
@deck.gl/core: 9.2.6
@luma.gl/core: 9.2.6
@luma.gl/engine: 9.2.6
Vite dev environment
Browser: Chrome
OS: macOS
Logs
Description
lHi team,
I hit an error inside luma.gl while debugging a Deck-based map application.
The exception stops in CanvasContext.getMaxDrawingBufferSize when reading:
this.device.limits.maxTextureDimension2D
From debugging, this is happening inside luma.gl rather than in my own app code.
Observed behavior
During resize / destroy / view transition related flow, CanvasContext.getMaxDrawingBufferSize can be called when device is not in a valid state anymore, and the method still directly reads device.limits.maxTextureDimension2D.
This appears to cause an exception when device is undefined, partially initialized, or otherwise invalid during that lifecycle window.
Expected behavior
CanvasContext.getMaxDrawingBufferSize should guard against an invalid or unavailable device state and either:
return a safe fallback size, or
skip the resize-related path gracefully
Environment
@deck.gl/core: 9.2.6
@luma.gl/core: 9.2.6
@luma.gl/engine: 9.2.6
Vite dev environment
Browser: Chrome
OS: macOS
Where it stops
CanvasContext.getMaxDrawingBufferSize
reading:
this.device.limits.maxTextureDimension2D
Why I think this is in luma.gl
I paused on the thrown exception in DevTools and the breakpoint landed in luma.gl source rather than my own wrapper code. The stack points into the canvas context resize / drawing buffer size path.
Potential fix direction
It may be enough to add a lifecycle guard before reading device.limits, for example handling cases where:
this.device is missing
this.device.limits is missing
the context is already destroyed / tearing down
If useful, I can also provide:
full call stack
screenshot from DevTools
a reduced repro if I can isolate it further
Thanks.
Flavors
Expected Behavior
No response
Steps to Reproduce
Possible patch idea
check whether this.device and this.device.limits are available before reading maxTextureDimension2D
if not available, fall back to current drawing buffer size or another existing safe fallback
optionally skip resize handling when context is already destroyed
Environment
@deck.gl/core: 9.2.6
@luma.gl/core: 9.2.6
@luma.gl/engine: 9.2.6
Vite dev environment
Browser: Chrome
OS: macOS
Logs