# windows: Fix message loop using too much CPU \(\#35969\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/b62f9595286d322e0a78daa73f58921c23a51d03)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: b62f9595286d322e0a78daa73f58921c23a51d03

Requested commit: b62f9595286d322e0a78daa73f58921c23a51d03

Commit: b62f9595286d322e0a78daa73f58921c23a51d03

Tree: 2d16f395b99aa552c4cef0dad83b25f089da0fd2

Author: 张小白

Committer: GitHub

## Message

```
windows: Fix message loop using too much CPU (#35969)

Closes #34374

This is a leftover issue from #34374. Back in #34374, I wanted to use
DirectX to handle vsync, after all, that’s how 99% of Windows apps do
it. But after discussing with @maxbrunsfeld , we decided to stick with
the original vsync approach given gpui’s architecture.

In my tests, there’s no noticeable performance difference between this
PR’s approach and DirectX vsync. That said, this PR’s method does have a
theoretical advantage, it doesn’t block the main thread while waiting
for vsync.


The only difference is that in this PR, on Windows 11 we use a newer API
instead of `DwmFlush`, since Chrome’s tests have shown that `DwmFlush`
has some problems. This PR also removes the use of
`MsgWaitForMultipleObjects`.


Release Notes:

- N/A

---------

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
```

## Parents

- [3a0465773050d0ce8319cc4a2276f688d72e7635](https://git.cafe/gitcafe/zed/commit/3a0465773050d0ce8319cc4a2276f688d72e7635?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/b62f9595286d322e0a78daa73f58921c23a51d03?format=markdown)