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

Very serious problem high CPU usage! #6308

Closed
sxzxs opened this issue Apr 6, 2023 · 8 comments
Closed

Very serious problem high CPU usage! #6308

sxzxs opened this issue Apr 6, 2023 · 8 comments
Labels

Comments

@sxzxs
Copy link

sxzxs commented Apr 6, 2023

Version/Branch of Dear ImGui:

Version: 1.89
Branch: viewport/docking

win32 dx11 win10

Back-ends: win32 dx11
Compiler: vs2022
Operating System: win10

My Issue/Question:

When its win32 dx11 binding process, minimize the interface, the utilization rate of CPU occupancy rate rise immediately to 50

Screenshots/Video
minisize
No nimisize

@ocornut
Copy link
Owner

ocornut commented Apr 6, 2023

We don't have an Idle process in place for minimization in our examples, and likely the app is running at maximum possible framerate since the Present() call doesn't wait for vsync.

Your application code can decide to pause when Minimized.

@ocornut
Copy link
Owner

ocornut commented Apr 6, 2023

Closing as duplicate of #2496
Aside from a more generic Idle scheme I suppose we could rework some of our example apps to simply stop when minimized.

@ocornut ocornut closed this as completed Apr 6, 2023
@sxzxs
Copy link
Author

sxzxs commented Apr 6, 2023

On the issue, I have found this problem, I'm sorry before without browsing
1、#3907
2、

	if (ImGui::GetIO().Framerate > 61.f) 
        {
		std::this_thread::sleep_for(std::chrono::milliseconds(200)); // drop to 5 FPS when invisible
	}

@ocornut
Copy link
Owner

ocornut commented Apr 6, 2023

The solution in #3907 is more correct than checking for Framerate > 61.f

ocornut added a commit that referenced this issue May 23, 2024
@ocornut
Copy link
Owner

ocornut commented May 23, 2024

I have pushed ec1d2be which seemingly solves it for both cases of minimization and screen locking. Implemented this for the DX9, DX10, DX11 and DX12 examples. Both DX9 and DX12 weren't burning as much CPU when looping with no visible swap chain, as Present() would still honor vsync, but it's still best to not loop when locked.

Note this issue for multi-viewports #7615 (comment)

@damian-kos
Copy link

I've noticed that when I statically link my builds against OpenGL 2 and OpenGL 3, the CPU usage in Task Manager can reach around 20%. In contrast, dynamically linking results in significantly lower CPU usage, typically between 1% and 3%.

Removing ImGui's code brings it back to normal values.

What could be causing this difference in CPU usage between static and dynamic linking?

@ocornut
Copy link
Owner

ocornut commented Oct 22, 2024

What does statically linking against OpenGL 2 and OpenGL 3 means?

@damian-kos
Copy link

Sorry my lack of experience showing up. So what I probably should've said is when I link against static libraries of SDL or GLFW. When I setup a new project I am using demos from the examples with SDL and GLFW installed with vcpkg without static command and they work what I assume fine.

Problem I mentioned is when I setup my project in VS with vcpkg using its manifest file with with 'Use Static Libraries' to Yes. The the issue occurs.

Doesn't happen on win32 - dx versions only on sdl/glfw - opengl

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

No branches or pull requests

3 participants