Can PIXI.Ticker expose configurable maxDelta to balance stability and responsiveness?

PIXI.Ticker’s delta computation is clamped to a maximum of 1/60 s when the event loop stalls, preventing a spiral of death but potentially desynchronizing game logic. This clamping is hard‑coded and not exposed to developers.

When requestAnimationFrame is unavailable or disabled, the ticker falls back to setTimeout, introducing a 4 ms minimum granularity on some mobile browsers. In these situations, the hard‑coded delta clamp can cause noticeable frame drops or jitter, especially in fixed‑step game loops that rely on consistent timing.

The current source does not provide a way to adjust the maximum delta value without modifying the library. An exposed configuration would allow developers to trade off between stability during stalls and responsiveness during normal operation, but it also introduces potential pitfalls if misconfigured.

Which design patterns would best expose a maxDelta setting while preserving backward compatibility?
Can a per‑ticker configuration be added without breaking existing code that relies on the current clamping behavior?
Does adding this option risk introducing new edge cases in headless or server‑side rendering environments?