Some commands in Command::batch are ignored if they finish too fast

[mtkennerly]

Issue

It seems like some commands in Command::batch are ignored if they finish too fast. The use case where I encountered this issue is that I have a progress bar that updates as batched commands finish, which worked fine until I added the ability to cancel the commands (making them return immediately based on an Arc<AtomicBool>), which caused the progress bar not to update all the way, like some of the commands were just ignored. It works if I add a sleep in the commands, though. I think/assume that update() is single-threaded, but just in case, I tried using AtomicU32 to store the progress bar value (and then converting it as f32 to pass to the component), but that didn't help.

Gist: https://gist.github.com/mtkennerly/b513e7fe89c735e5a5df672c503404d7

Demo (first without a sleep, then with a sleep of 1 millisecond):

Environment

• OS: Windows 10
• Rust: 1.44.1
• Toolchain: stable-x86_64-pc-windows-msvc
• Iced: Applies to both 0.1.1 and the latest master commit (dfeb3db003d724a1c980329dab9cbfae55b7f589). I recorded the above demo using master.

[hecrj]

Thanks for the detailed report and the SSCCE! 🎉

I can reproduce the issue on Windows and I tracked it down to the winit::EventLoopProxy. Specifically, I have verified that all the commands do indeed finish and the messages are sent to winit here:

https://github.com/hecrj/iced/blob/dfeb3db003d724a1c980329dab9cbfae55b7f589/winit/src/proxy.rs#L45

However, the Windows implementation of EventLoopProxy in winit seems to be dropping some of them. If they are using a bounded buffer, I believe the API should expose additional errors. We will have to investigate further.

The issue does not seem to affect Linux with X11. The example works fine there.

[hecrj]

We should check if the issue is still present in the latest winit release.

[mtkennerly]

The issue is still present, unfortunately.

Updates from the gist:

diff --git a/Cargo.toml b/Cargo.toml
index 789f7be..2213325 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -2,8 +2,7 @@
 name = "repro"
 version = "0.1.0"
 authors = ["mtkennerly <[email protected]>"]
-edition = "2018"
+edition = "2021"

 [dependencies]
-# iced = "0.1.1"
-iced = { git = "https://github.com/hecrj/iced" }
+iced = "0.4.2"
diff --git a/src/main.rs b/src/main.rs
index ed98725..decf112 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -83,5 +83,5 @@ impl Application for App {
 }
 
 fn main() {
-    App::run(iced::Settings::default())
+    App::run(iced::Settings::default()).unwrap();
 }

Cargo.lock:

[[package]]
name = "winit"
version = "0.26.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9b43cc931d58b99461188607efd7acb2a093e65fc621f54cad78517a6063e73a"

[menoua]

Is this issue potentially related to issue #792?

I've had the same bug as the OP of that issue on macOS Monterey in two separate applications now: sometimes (> 10%) when the update function finishes too fast the screen doesn't refresh to reflect the new state. Moving the mouse the slightest bit, pressing any key, or receiving a new command forces a refresh showing that the state had in fact been updated in the previous step.

I've found two solutions to this so far.

1. If I ensure that all view-changing updates take at least 2ms by adding thread::sleep, the problem disappears. This is my currently preferred approach.
2. Switching to glow also fixes the problem. This is not helpful to me as the glow backend lacks a lot of the wgpu functionality (image, svg, etc.), but shows the issue is in the wgpu space.

[mtkennerly]

Here's a new gist for Iced 0.5.2: https://gist.github.com/mtkennerly/c604cc74f2087d4827f9c8513ee0447f

For me (Windows 11), the issue occurs with both wgpu and glow.