-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
eframe
on Windows high CPU usage due to excessive calls to glutin::context::make_not_current
#4173
Comments
I think this was introduced in #3172 when we added support for multiple viewports. When there are multiple viewports we need to switch to which has the "current" gl context, and we unfortunately pay this cost even when there is only one viewport, but that should be fixable. |
Is there a workaround for now (i.e. options to disable multi-viewport)? (Apart from reverting to an older version) |
This is still an issue on Windows. If someone wants to work on this, please take a look at |
Seems that the reverted fix (#4284), even when it wasn't reverted before still did not fix the issue. CPU load does not noticeably decrease and still hovers around 30% on my machine in the |
With a single viewport... yeah I took a spin at it but didn't get far yet. Will report back if I find something |
…since it is reportedly broken on Windows * Early-out added in emilk#4284 * Re-opens emilk#4173 😭 * Closes emilk#4289 * Closes emilk#4290
I noticed that my application CPU usage was much higher than expected on Windows. On a similar machine I was seeing 1%-2% usage on Linux, and around 20%-30% on Window while moving the mouse in window (just mouse movement).
After some optimization I got my rendering loop down to less than 1ms and still the CPU usage was too high. I then sampled the CPU with https://github.com/nico-abram/blondie/tree/main and this is the flamegraph that it produces:
As you can see, almost 90% of the time, it is calling the
make_not_current
function, which seems really excessive...EDIT: I found in the docs here that this call flushes the rendering context so probably rendering is just very slow... Still not sure why though.
Screenshots
Another flamegraph with Windows Performance Analyzer (similar results):
This shows the call stack a bit deeper:
wglMakeCurrent
bMakeNoCurrent
wglMakeCurrent
wglMakeCurrent
wglMakeCurrent
SetEvent
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: