Window::request_redraw() inside WindowEvent::RedrawRequested is slow on Wine

[madsmtm]

Reported by @John-Nagle in #3373 (comment).

[kchibisov]

They run under wine without any logs. They should open a proper issue with example and how to repro, because I can't repro that myself and that's what we do in e.g. alacritty with much issues.

However the WM_PAINT is just broken concept and shouldn't be used, but it's a separate issue.

[John-Nagle]

Ref: Rend3 Issue #570

Ref: Wine issue

This is an issue when Rend3, Winit, and Wine are all used together. It's not clear who is supposed to deal with it. I'm currently dealing with it at the application level. That required a patch to Rend.

The basic question is, when should request_redraw be called? Current Winit documentation says to call it at the end of each redraw, so there's always a redraw request event pending. (Hopefully only one such request.) This works terribly under Wine if the main thread is compute-bound. Requesting redraw only on the AboutToWait event solves the problem.

From a quick look at the Winit code, at least for the Windows platform, event processing is just a pass-through of the platform's event processing. When running under Wine, the event loop is actually code in a .DLL file dynamically linked into the program executing under Wine.

[kchibisov]

The basic question is, when should request_redraw be called? Current Winit documentation says to call it at the end of each redraw, so there's always a redraw request event pending. (Hopefully only one such request.) This works terribly under Wine if the main thread is compute-bound. Requesting redraw only on the AboutToWait event solves the problem.

Keep in mind that it'll send a redraw for the next frame, and also, even if you're compute bound it shouldn't be a big issue. I think the issue is that redraw_requsted in winit is modeled with WM_PAINT, and WM_PAINT is generally a not good mechanism for any of that. We should probably leave it alone and just do it ourselves via some sort of channel bypassing the WM_PAINT all together.

I think the initial idea for all of that was to not render faster than os can handle (apps that don't want that can just never request a redraw and use their own logic for stuff like that.

I'm also not sure what is your issue in particular with compute bound here? Do you have a gap between redraws where in reality you just want?

Also, I've just noticed that you're using winit 0.28, could you please test with 0.29.12? A lot of things changed since 0.28.0.

[John-Nagle]

I now have some Tracy traces. These use Winit 0.29.4. locked by rend3-framework.

In this session, towards the end, the character moved on screen for three seconds after releasing the arrow key.
The Rend3 framework has two callbacks - redraw, and all other events. So here are the profiles of those two. Longest processing time for "event" was 8ms. Longest processing time for "redraw" was 121ms, but that was an outlier. Mean time was 15ms. So nothing in that thread went compute-bound or was blocked long enough to explain a key repeat delay of several seconds.

[John-Nagle]

Oh, and change this back to "Open", please.

[kchibisov]

Could you please test with 0.29.12 and not 0.29.4?

[John-Nagle]

Could you please test with 0.29.12 and not 0.29.4?

Not easily. I'm not a direct user of Winit. It's used by Rend3, which locks the version.

[kchibisov]

it's a patch update, you should be able to cargo update -p winit, unless the lock a specific patch, which is weird. Though, I don't see us changing much around it and trying to grasp from your issue is also description is rather hard.

Could you try to simulate what you're doing with example? You can just sleep, so have more clear reproducer to work with. Create a separate issue for that since it's more concrete and inculde the env you've been using.

[John-Nagle]

There's already ui-mock as an example. Use branch "arc2". Build that with whatever version of Winit you want to test.