[macOS] full screen is super slow

[seivan]

Previously in gfx-rs/wgpu#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 gfx-rs/wgpu#337 making a difference.

Also, we could possibly optimize this inner loop out:

                    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 Fix life cycle of swap chain framebuffers wgpu#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 Fix life cycle of swap chain framebuffers wgpu#337

[seivan]

Fixed in 0.4 :)