Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new example for blocking functions #840

Merged
merged 13 commits into from
Apr 29, 2020

Conversation

mastfissh
Copy link
Contributor

It's not super obvious how to offload processing to other threads. If you run heavy processing on the UI thread, the experience is quite bad - you get a "not responding" prompt on windows, and things stop updating. To make it easier for others to do this, I've added this as an example.

Copy link
Collaborator

@futurepaul futurepaul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a wonderful example and I'm going to refer to it a lot. I took this code and with a few modifications made a file hasher.

My only complaint is the length of the example name. For some reason I don't have autocomplete when typing cargo run --example tktk. Maybe just call it blocking_function.rs?

druid/examples/processing_on_other_threads.rs Outdated Show resolved Hide resolved
});
}

impl AppDelegate<AppState> for Delegate {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wrapping my whole app in a Controller, this is a way better solution!

@mastfissh
Copy link
Contributor Author

Sounds good, I've renamed it to blocking_function.rs.

@cmyr
Copy link
Member

cmyr commented Apr 14, 2020

just a heads up I'd like to take a look at this before it goes in. :)

@cmyr cmyr self-requested a review April 15, 2020 14:08
Copy link
Member

@cmyr cmyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! this will need a bit of cleanup and explanation before it's ready to merge, and I have a few other little comments, but looks like a helpful illustration.

druid/examples/blocking_function.rs Outdated Show resolved Hide resolved
druid/examples/blocking_function.rs Outdated Show resolved Hide resolved
druid/examples/blocking_function.rs Outdated Show resolved Hide resolved
druid/examples/blocking_function.rs Outdated Show resolved Hide resolved
let either = Either::new(|data, _env| data.processing, button_placeholder, button);

Flex::column().with_child(label).with_child(either)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one problem with this example is that it isn't actually clear that we aren't blocking when we're doing the background work. I might try and make it slightly more complicated, maybe so that there are two counters, and we can increment the other one while the background task is happening? Or even just drawing some sort of progress indicator?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reluctant to add more complexity to this example, because I think there's a lot of value in making sure it's easily adaptable and easily understood, even to people new to druid.

I also think because of the nature of this example, proving that it's non-blocking isn't too necessary. When I had a blocking function freeze up my window on my project, I immediately had a look in examples to see if there was a pattern for dealing with that situation. I haven't tested it on linux or macos, but at least on windows it's very hard to miss when the UX thread is blocking - it locks up, the UX around it fades, and it'll offer to terminate it for you.

That said, if you think it's important to have two bits of UX running at the same time, I think a progress indicator makes the most sense.

@cmyr cmyr added the S-waiting-on-author waits for changes from the submitter label Apr 17, 2020
@mastfissh
Copy link
Contributor Author

@cmyr, not sure if you've seen my comment?

Copy link
Member

@cmyr cmyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think this is a good addition as is. Thanks!

@cmyr
Copy link
Member

cmyr commented Apr 28, 2020

Looks like you're going to need to explicitly ignore this example in examples/wasm/build.rs.

@xStrom
Copy link
Member

xStrom commented Apr 28, 2020

This PR needs to be rebased with master to get past CI.

@cmyr cmyr merged commit 14ae563 into linebender:master Apr 29, 2020
@cmyr
Copy link
Member

cmyr commented Apr 29, 2020

Thanks @mastfissh!

@mastfissh mastfissh deleted the blocking_example branch April 29, 2020 14:24
@xStrom xStrom removed the S-waiting-on-author waits for changes from the submitter label May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants