Wgpu-rs: [macOS] full screen is super slow

[seivan]

Previously in https://github.com/gfx-rs/wgpu/issues/78 mentioned that full screen leaks memory and is super slow, but now it's just slow, no longer leaks memory.
I don't see excessive swapchain recreation, it just slow on its own. I haven't checked a trace yet but will do that eventually.

[kvark]

Great, thanks for the update!
Looking forward to see what you find.

[parasyte]

Now that the swapchain recreation issue is resolved, I still see this behavior with full screen.

The only info I have to add here is that dragging the corners of the window (e.g. on the shadow example) to the maximum size only uses about 25% CPU. When I press the green fullscreen button it's suddenly CPU bound using just over 100% CPU.

Even though the physical size is extremely close, there is something horrible going on that is not obvious from logging.

25% CPU, stretch window:

[2019-09-10T06:59:33Z INFO  shadow::framework] Resizing to PhysicalSize { width: 3840.0, height: 2310.0 }

105% CPU, fullscreen:

[2019-09-10T06:59:53Z INFO  shadow::framework] Resizing to PhysicalSize { width: 3840.0, height: 2400.0 }

Here are some logs from the transition to fullscreen. Nothing else stands out as relevant: https://gist.github.com/parasyte/de9695f8322bf4fd92fb70eddf3f0c0a

[kvark]

Could somebody just make a good Instruments CPU capture and see what we are doing in those 100%?

[TheMDev]

Yeah, I just started looking into instruments recently for debugging ill see what I can do within the next few days.

[parasyte]

Here's what I got: profiles.zip

• normal.trace is the shadow example running as usual
• fullscreen.trace shows the high CPU load while the shadow example is running fullscreen
• background.trace shows a new failure mode where the CPU usage comes in large bursts while the window is hidden behind another (but not full screen).

[parasyte]

If I'm reading the profiles correctly, this nested iteration can be super heavy: https://github.com/gfx-rs/wgpu/blob/499bf1d2686ad25b5a5133d6433e4f4c9179ff0b/wgpu-native/src/device.rs#L379-L395

WDYT?

[kvark]

Thank you for sharing the profiles!
If that code is the problem, we may see https://github.com/gfx-rs/wgpu/pull/337 making a difference.

Also, we could possibly optimize this inner loop out:
```rust
for a in &self.active {
if a.resources.iter().any(|&(ref id, _)| id == res_id) {
last_submit = last_submit.max(a.index);
}
}
````

I don't understand though how this code is different between windowed and fullscreen - it's supposed to do exactly the same thing.

[kvark]

Alright, I did some profiling locally and I think I found all the wrongs we do:

1. the triage_framebuffers shows up heavily because of the problem https://github.com/gfx-rs/wgpu/pull/337 is fixing
2. nextDrawable is super slow and blocking us because we take the minimum number of images for the swapchain, it's addressed by https://github.com/gfx-rs/wgpu/pull/337

[seivan]

Fixed in 0.4 :)