requestAnimationFrame loop keeps running in render modes on-demand, manual

[vincesp]

Describe the bug

As a developer, I expect CPU usage of my browser tab to drop to 0% if using render-mode "on-demand" or "manual".
Actual behavior: requestAnimationFrame loop keeps running, CPU usage of 2%.

Reproduction

https://stackblitz.com/edit/tresjs-minimal-reproduction-4fdedjcb?file=src%2FApp.vue

Steps to reproduce

Run the stackblitz and observe the console in the developer tools. It will print "advance" once and then "loop" continuously, clocking away CPU cycles needlessly.

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @tresjs/cientos: ^5.1.0 => 5.1.0 
    @tresjs/core: ^5.1.0 => 5.1.0 
    @tresjs/leches: ^0.14.0 => 0.14.0 
    vite: ^6.0.3 => 6.0.5

Used Package Manager

npm

Code of Conduct

• I agree to follow this project's Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[reistence]

I can reproduce this on main (17248d4). The render is correctly skipped, but the rAF loop keeps spinning.

I mounted TresCanvas in each render mode, let it settle for 400ms (past the useTimeout(100, advance) that manual mode fires on startup), then counted renders and loop hook calls over a 200ms idle window:

render mode	renders	loop hooks
always	23 → 34	23 → 34
on-demand	1 → 1	23 → 35
manual	1 → 1	23 → 35

In always every loop tick produces a render, which is what you'd expect. In on-demand and manual the loop has ticked 35 times to produce a single frame, and it keeps ticking (+12 per 200ms) with nothing left to render.

The loop is started for every render mode and never stopped:

tres/packages/core/src/composables/useRenderer/useRendererManager.ts

Lines 337 to 350 in 17248d4

	const loop = useCreateRafLoop(() => {
	if (frames.value) {
	renderFunction(notifyFrameRendered)
	}
	}, {
	fpsLimit,
	})
	// Only start the render loop after renderer initialization is complete
	readyEventHook.on(() => {
	if (isInitialized.value) {
	loop.start()
	}
	})

The if (frames.value) guard prevents the render, but each frame still calls timer.update(), allocates the context object and triggers the before/after hooks. That's why @vincesp sees advance logged once and loop logged forever.

The docs lean on these modes for exactly this reason — the performance guide warns that always-on rendering "might drain your device battery" and recommends on-demand or manual "for static or mostly-static scenes to save resources and improve battery life" — so the idle loop seems worth fixing rather than treating as an implementation detail.

Happy to open a PR, but one design question first. useLoop() wires user callbacks straight onto those hooks (onBeforeLoop/onLoop in useLoop/index.ts), so pausing the loop once frames reaches 0 would also stop anything registered through useLoop().onBeforeRender(). In on-demand I'd argue that is correct, since the point of the mode is not doing per-frame work, but it is observable for anyone relying on those callbacks to drive update logic. Which would you prefer?

1. Pause and resume the loop around invalidate() and advance() — fixes the CPU usage, changes callback behaviour.
2. Keep the loop running but skip the timer and hook work when there is nothing to render — smaller win, no behaviour change.

I'd lean towards the first, with the caveat called out in the render modes docs.

There are also no tests covering renderMode in packages/core at the moment, so I would add the ones I wrote for this repro.