BabylonJS/Babylon.js · error · Error
Not Supported by ThinEngine
Error message
Not Supported by ThinEngine
What it means
The performanceMonitor getter is not implemented in ThinEngine — only the full Engine class provides a PerformanceMonitor. ThinEngine is the minimal WebGL backend, so this API surface is intentionally unsupported and always throws.
Source
Thrown at packages/dev/core/src/Engines/thinEngine.pure.ts:1034
}
/**
* End the current frame
*/
public override endFrame(): void {
super.endFrame();
// Force a flush in case we are using a bad OS.
if (this._badOS) {
this.flushFramebuffer();
}
}
/**
* Gets the performance monitor attached to this engine
* @see https://doc.babylonjs.com/features/featuresDeepDive/scene/optimize_your_scene#engineinstrumentation
*/
public get performanceMonitor(): PerformanceMonitor {
throw new Error("Not Supported by ThinEngine");
}
/**
* Binds the frame buffer to the specified texture.
* @param rtWrapper The render target wrapper to render to
* @param faceIndex The face of the texture to render to in case of cube texture and if the render target wrapper is not a multi render target
* @param requiredWidth The width of the target to render to
* @param requiredHeight The height of the target to render to
* @param forceFullscreenViewport Forces the viewport to be the entire texture/screen if true
* @param lodLevel Defines the lod level to bind to the frame buffer
* @param layer Defines the 2d array index to bind to the frame buffer if the render target wrapper is not a multi render target
*/
public bindFramebuffer(
rtWrapper: RenderTargetWrapper,
faceIndex: number = 0,
requiredWidth?: number,
requiredHeight?: number,
forceFullscreenViewport?: boolean,
View on GitHub (pinned to 0592b347b8)
Solutions
- Use the full Engine class (from packages/dev/core/src/Engines/engine.ts) if you need performanceMonitor
- Guard the access: check typeof engine.performanceMonitor or instanceof ThinEngine before reading
- Implement your own PerformanceMonitor around render loop timing if staying on ThinEngine
- Track engine feature support via the engine's capabilities instead of assuming full Engine API
Example fix
// before
const fps = engine.performanceMonitor.average; // throws on ThinEngine
// after
if (!(engine instanceof ThinEngine)) {
const fps = engine.performanceMonitor.average;
} Defensive patterns
Strategy: type-guard
Validate before calling
function supportsPerformanceMonitor(engine: unknown): boolean {
return !(engine instanceof ThinEngine);
} Type guard
function hasPerformanceMonitor(e: any): e is { performanceMonitor: PerformanceMonitor } {
return e && typeof e === 'object' && 'performanceMonitor' in e && !(e instanceof ThinEngine);
} Try / catch
try {
const avg = (engine as any).performanceMonitor.average;
} catch (e) {
if ((e as Error).message === 'Not Supported by ThinEngine') {
const avg = ownFrameTimeAverager(); // custom fallback
}
} Prevention
- Use the full Engine class when you need Engine-level features (monitor, deltas, etc.)
- Wrap thin-engine access behind an interface that only declares supported APIs
- List ThinEngine exclusions when writing engine-agnostic utility code
- Add an instanceof check before accessing optional engine APIs
When it happens
Trigger: Accessing engine.performanceMonitor on an instance of ThinEngine (or ThinWebGPUEngine-style thin engines) instead of the full Engine class; calling it in library code typed loosely as any engine.
Common situations: Using ThinEngine directly for lightweight rendering and assuming the full Engine API exists; sharing utility code between Engine and ThinEngine instances; upgrading refactors that swapped Engine for ThinEngine without auditing API usage.
AI-assisted analysis of BabylonJS/Babylon.js@0592b347b8 (2026-08-30).
Data as JSON: /api/errors/ce2c96a007794c03.
Report an issue: GitHub.