Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lowering the strain of the render loop when it's not being used #251

Open
Ctrlmonster opened this issue Dec 4, 2024 · 1 comment
Open
Labels
Help wanted Extra attention is needed New feature New feature or request

Comments

@Ctrlmonster
Copy link

For low end devices it can be important to enable render on demand for the Triplex canvas. Especially if the user has Triplex and the final App open at the same time, this puts a lot of pressure on the device.

A simple way to enable render on demand is to add a timeout duration for user interaction, e.g. on every user interaction (mousemove etc) reset the timer (i.e. 3 seconds) and invalidate the canvas until the timer has run out.

This should likely be a config setting though, 100% reliable render on demand is hard to achieve. For example, you might not know whether the user has an animation running that they want to inspect in the editor. Here it's probably best to give the user direct control over whether demand rendering should be enabled and what the timeout value should be.

@itsdouges itsdouges added the New feature New feature or request label Dec 6, 2024
@itsdouges itsdouges changed the title render on demand option for triplex editor Lowering the strain of the render loop when it's not being used Dec 6, 2024
@itsdouges itsdouges added the Help wanted Extra attention is needed label Dec 6, 2024
@itsdouges
Copy link
Collaborator

@krispya quick thoughts on this: we could have the frame loop fire once a second while the editor isn't focused. We could accomplish this by forcing the canvas frameloop to "demand" and then orchestrating our own timers. This would be more desirable than completely turning it off because then updates would be flushed into the editor when doing code first development.

One nuance here is we probably shouldn't set it to a static every 1 second, something like progressively getting slower over time until it reaches some floor, and then with a HMR event or a webview focused event we start it up again to the standard "always" and then flip back to progressively getting slower.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help wanted Extra attention is needed New feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants