找到
1
篇与
DWM
相关的结果
-
浏览器/应用部分卡顿 鼠标拖到地方之后刷新 具体表现 在浏览网页时，切换页面后屏幕部分区域还停留在上一页面的画面，只有其余区域能正常更新；或者在新页面滚动时，页面内容在某些区域能随滚动变化，但整体框架却保持不动。 切换应用窗口时，新窗口没有完全刷新，部分区域依然残留着上一个程序的画面。 向下滚动时，窗口的上半部分会突然停住不动，好像被冻结，但下半部分依然能正常滚动，过一段时间整个窗口才会恢复正常。这种情况在 Chrome 以及其他软件里都会出现，大约每隔几分钟就会发生一次。 解决方法 按住 Win + R 打开运行，输入 regedit 打开路径 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm 新建一个 DWORD(32) ，值为 5 重新启动电脑即可 原因 Windows 11 24H2 里 桌面窗口管理器(DWM) 对 多平面叠加(MPO) 状态切换处理有 bug → 导致 Chromium/Electron 应用在交互时卡顿。 一篇来自 Reddit 的帖子详细分析了此现象 The cause? Microsoft.. specifically Desktop Window Manager(DWM) and it's interaction with MPO. As for why, when using PresentMon, I noticed VSCode and Discord would have their flip presentation model fluctuate between Composed: Flip and Hardware Composed: Independent Flip during active usage, the latter I believe is when a MPO plane is assigned. Discord doesn't need to render out a new frame if nothing has changed, thus its overall fps can be rather low. When interacting with the GUI, frames are rendered to respond to your input and can trigger DWM to change its flip model. It seems something goes very wrong with this back and forth behavior. Interestingly, Firefox doesn't appear in PresentMon and doesn't have an issue.大意是： Windows 桌面窗口管理器（DWM） 在 24H2 中和 多平面叠加（MPO, Multi-Plane Overlay） 的交互存在问题。像 VSCode、Discord、Chrome/Edge（基于 Chromium 的应用）在渲染时使用 翻转呈现模型 (Flip Presentation Model) ，它会在两种状态之间切换： Composed: Flip → 由 DWM 进行合成 Hardware Composed : Independent Flip → 直接分配一个 MPO 平面，绕过部分 DWM 当你滚动、拖动、交互时，DWM 不停在这两种状态之间切换。这种来回切换会导致 合成器混乱 ，从而出现 卡顿、残影、界面不刷新 。 Discord 这类应用在界面静止时会降帧（节省资源），只有交互时才瞬间输出帧 → 正好触发 DWM/MPO 的切换 bug，更容易卡顿。 Firefox 没有这个问题，因为它用的是另一套呈现路径，不会出现在 PresentMon 的 flip 模式切换里。
