"pixi.js: WebGL not supported" – suppressing console noise while keeping critical alerts

Direct answer

The cleanest fix is not to filter the console at all: check WebGL support before creating the renderer, so PixiJS never reaches the code path that logs the message. For everything else, wrap console.error/console.warn once at startup with a narrow substring filter, and leave loader error events wired to your own handler so critical failures still surface.

Why the message appears

pixi.js: WebGL not supported means the browser failed to hand PixiJS a WebGL context — a disabled GPU, blocklisted driver, headless environment, or exhausted context limit. It is an environment fact, not a bug in your scene code. Because PixiJS logs it during renderer creation, the only way to keep it from appearing is to decide before creation what to do.

Step 1: Pre-check support and branch

In PixiJS v6/v7, PIXI.utils.isWebGLSupported() runs the same probe the renderer would. Gate initialization on it:

import * as PIXI from 'pixi.js';

if (PIXI.utils.isWebGLSupported()) {
  const app = new PIXI.Application({ width: 800, height: 600 });
  document.body.appendChild(app.view);
} else {
  // One deliberate, visible notice — not console spam
  showFallbackBanner('Your browser does not support WebGL.');
  // Optional: explicit canvas fallback instead of letting autoDetect throw
  // const app = new PIXI.Application({ forceCanvas: true });
}

Because you branch first, the internal warning path never executes, and the user gets a controlled message instead of a console line. In v8 the renderer API changed to async Application.init() with preference: 'canvas' as the fallback option — verify against your installed version with npm list pixi.js, since the option names differ across majors.

Step 2: Selective console filtering (only if you still need it)

If a dependency or test harness still triggers the message, wrap the console once, match narrowly, and forward everything else untouched:

const originalError = console.error.bind(console);
const SUPPRESSED = ['WebGL is not supported'];

console.error = (...args) => {
  const first = String(args[0] ?? '');
  if (SUPPRESSED.some(s => first.includes(s))) return;
  originalError(...args);
};

Two rules keep this safe. First, never blanket-silence console.error — shader-compile failures and texture decode errors travel the same channel and are exactly the "genuine runtime problems" you want to see. Second, keep the match list short and documented; string matching is brittle across PixiJS releases and locales.

Answering the unresolved questions

• Does PIXI.settings.STRICT = true suppress logs? No. STRICT changes internal behavior (stricter validation/exceptions); it is not a log-level control. Do not rely on it for console hygiene.
• Overriding the loader's error logging? Rather than patching PixiJS internals, attach your own onError handler to the loader (v6) or wrap Assets.load in try/catch (v7+). Log each failure once with the asset URL, and rethrow or escalate failures for assets your scene cannot run without. That keeps critical alerts in your control instead of PixiJS's default logging.
• Best practice for the WebGL message? Prevention via isWebGLSupported() (or a try/catch around renderer creation) beats post-hoc filtering. Reserve console wrapping for environments you don't control, such as CI.

Headless and CI environments

In jsdom or headless CI, the message is expected and harmless. Gate PixiJS initialization behind the same capability check, or mock the renderer in tests, rather than filtering logs after the fact.

One thing that is not noise

Losing WebGL at runtime is a different, critical event. Listen for webglcontextlost on the canvas and treat it as an alert — never route it through your suppression filter:

app.view.addEventListener('webglcontextlost', (e) => {
  e.preventDefault();
  notifyUser('Graphics context lost — reloading.');
});

Verification

1. Launch Chrome with --disable-webgl and confirm your capability branch runs and no PixiJS warning appears.
2. Load a deliberately broken texture URL and confirm the error still reaches the console and your handler.
3. Confirm the installed version (npm list pixi.js) matches the renderer API your code uses.

Version note: option names and the loader/Assets API differ between PixiJS v6, v7, and v8; the snippets above target v6/v7 and should be checked against your installed release.