Improve model loading messages (long-lived background thread)

[zthompson47]

This PR fixes #1431 and fixes #1327 by spawning a host background thread that lives outside of the the event loop. A handle is used inside the event loop to send new models for processing. Status messages are sent back to the event loop via winit::event_loop::EventLoopProxy.

[hannobraun]

Thank you, @zthompson47, this is great!

I tested this, and it works great. I also reviewed the code and it looks good. I left comments where things jumped out to me, but none of that is a blocker.

You said that you wanted to do more cleanup and write tests before merging. While that would be very welcome, I'd be more than happy to merge this as-is. It is a clear improvement, after all, fixing two issues!

Additional cleanup and testing can be submitted in follow-up pull requests. This would also reduce the likelihood of other pull requests causing merge conflicts here in the meantime. What do you think?

One caveat: I haven't looked at #1477 yet (will do so soon), so maybe I'll end up liking that better. However, based on our conversation in #1431, I believe that the "long-lived thread" approach from this pull request is likely to be the better one.

[hannobraun]

See previous comment about #![allow(...)].

[zthompson47]

Thanks for review and comments - very helpful!

| Additional cleanup and testing can be submitted in follow-up pull requests
That sounds good to me. I think your comments addressed most of the cleanup I was thinking of, and the tests might end up being a bit of a project.

I'll resolve the above conversations and we can merge this in.

[hannobraun]

Thank you, @zthompson47, those latest changes look great!

I just did a rebase to get this up-to-date with main, and will merge as soon as CI is green.

[zthompson47]

Thanks for all the help getting that PR merged!

I never did that last edit to sort out the issue with #![allow(clippy::result_large_err)]. Still getting used to the workflow on github, but sounds like I'll just wrap that up and put it in a new PR (with no issue filed).

[hannobraun]

Thanks for all the help getting that PR merged!

No problem. It was you who did all of the work!

I never did that last edit to sort out the issue with #![allow(clippy::result_large_err)]. Still getting used to the workflow on github, but sounds like I'll just wrap that up and put it in a new PR (with no issue filed).

Different projects handle that kind of stuff differently. Myself, I'm pretty flexible in how to do things, as I want to encourage contributions, and I don't think it's reasonable to expect every contributor to read a thick "how we do it" handbook. That said, these are my preferences:

• Open pull requests basically are a burden for everyone involved. Mostly for their author, because as long as they stay open, they tend to accumulate merge conflicts that need to be fixed, as more changes are being made to the main branch. That's why I prefer to merge them as soon as I feel they are an improvement, even if they have problems.
• If I merge a pull request with problems that I feel are important, I open an issue right after merging. That way, we can be sure the problem isn't forgotten, even if it's not handled right away.
• Like open pull requests, open issues also have a cost. The more you have, the harder it becomes to stay on top of them, and the more likely they are to get out of date. At the extreme end, it becomes easier to just test the app and look at the code to figure out what can be improved, than sorting through issues.
• I think the #![allow(clippy::result_large_err)] thing isn't quite important enough to warrant an open issue. It would still be a welcome improvement, but it's not the kind of thing we need to track through an open issue. If you wanna do it, great! Just open another pull request. If not, someone else can improve it whenever they come across it.