-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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 |
Hello @rainbyte,
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 👍 |
I saw the Thanks for the confirmation. Using Having |
Hello @rainbyte I'll add some mild throttling to 👍 |
@lettier , that would be nice. I have also created a PR adding an iterate example to the documentation. |
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 toWHS.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?
The text was updated successfully, but these errors were encountered: