mirror of
https://github.com/ocornut/imgui.git
synced 2026-10-18 19:13:38 +00:00
Very serious problem high CPU usage! #6308
Labels
No labels
accidentally closed
android
backends
bug
building
clipper
coloredit
color spaces
cplusplus
data types
demo
disabled
doc
docking
dpi
drag drop
drawing/drawlist
dropped
dx12
enhancement
focus
font/text
gallery
help wanted
idle/power saving
ime
in progress
inputs
inputtext
internals
label/id and id stack
language bindings
layout
linux/bsd
menus
multi-contexts
multi-threading
multi-viewports
nav
news/info
opengl
optimization
osx/ios
overlap
plot/graph
popups
question
scrolling
selection
settings
sliders/drags
style
tables/columns
tabs
test wanted
tools
tooltips
tree
tricks & tips
useful widgets
vulkan
web
window pos/depth
window sizing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ocornut/imgui#6308
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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


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.
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.
On the issue, I have found this problem, I'm sorry before without browsing
1、https://github.com/ocornut/imgui/pull/3907
2、
The solution in #3907 is more correct than checking for
Framerate > 61.f