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

High cpu usage on WHS.withWindowLoop iteration function #4

Open
rainbyte opened this issue Dec 17, 2019 · 5 comments
Open

High cpu usage on WHS.withWindowLoop iteration function #4

rainbyte opened this issue Dec 17, 2019 · 5 comments

Comments

@rainbyte
Copy link

When using WHS.withWindowLoop as explained in the documentation, webviewhs starts to consume a high percentage of CPU (100% load almost all the time the app is running).

I have managed to find that the problem is related to the iteration function passed to WHS.withWindowLoop.

As a workaround I have changed (\window -> pure True) to (\window -> threadDelay 8333 $> True), so it updates at ~120fps.

I think my workaround is not the ideal solution. Is there other expected (undocumented) way to handle this or is it a bug?

@rainbyte rainbyte changed the title High cpu usage High cpu usage on WHS.withWindowLoop iteration function Dec 17, 2019
@rainbyte
Copy link
Author

rainbyte commented Dec 17, 2019

It is also possible to regulate how much time to wait, but it is still just a workaround

windowIteration lastTimeRef window = do
  currTime <- getCurrentTime
  lastTime <- readIORef lastTimeRef
  writeIORef lastTimeRef currTime
  let dtFloat = (realToFrac $ diffUTCTime currTime lastTime) :: Double
      dtMsecs = floor $ dtFloat * 1000000
      nextFrame = 8333 - rem dtMsecs 8333
  threadDelay nextFrame
  pure True

@lettier
Copy link
Owner

lettier commented Dec 18, 2019

Hello @rainbyte,

threadDelay, like you've shown, would be the way to loosen such a tight loop. Otherwise, the loop will consume as many CPU cycles as it can.

I would say it's up to the application to control how fast it runs but I could incorporate some convenient, configurable throttling mechanism into the API if you'd like.

If you need total control over the loop there is iterateWindowLoop. You would use that instead of withWindowLoop as that's what withWindowLoop uses. With iterateWindowLoop, your application can run one iteration of the webview when it needs to. For example, you could stop processing the webview while some computation runs on the Haskell side.

👍

@rainbyte
Copy link
Author

rainbyte commented Dec 20, 2019

I saw the iterateWindowLoop when reading the withWindowLoop implementation, so I copied the code, simplified it a little bit, and changed it to add the fps handling by hand.

Thanks for the confirmation. Using iterateWindowLoop seems to be the way to go, because it is more flexible. Maybe it could be mentioned in the main documentation.

Having withWindowLoop just for small examples is good too. What about adding a default framerate to it without changing the api or at least a warning?

@lettier
Copy link
Owner

lettier commented Dec 26, 2019

Hello @rainbyte

I'll add some mild throttling to withWindowLoop.

👍

@rainbyte
Copy link
Author

@lettier , that would be nice.

I have also created a PR adding an iterate example to the documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants