EmbarkStudios / texture-synthesis

🎨 Example-based texture synthesis written in Rust 🦀

Home Page:http://embark.rs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Signal progress when compiling for wasm32

bnjbvr opened this issue · comments

In native mode, progress can be signaled to the user by passing a GeneratorProgress implementation. The WebAssembly mode doesn't support signaling progress, which looks like a not-implemented-yet situation rather than something impossible to solve. So I'd like to add this :-)

Describe the solution you'd like
The code used to compute the current progress percentage could be generalized into a small notifier (not a final name!) data structure/closure wrapping the GeneratorProgress, and passed as an Optional parameter to worker_fn in lib/src/ms.rs.

The main progress loop in the worker would signal progress, if the parameter is not None. In the case of native, a None argument is passed to each worker_fn call. In the case of wasm, the notifier is passed to the one worker_fn call. This is future-proof in the sense that even if wasm multi-threading support was added, the borrow-checker would complain about multiple mutable ownership of the notifier.

Describe alternatives you've considered

  • the above solution is the path of least resistance, but it'll a dynamic check (to check if the Option is some) for each iteration of the progress loop, in both native and wasm. With a little effort, maybe the worker_fn function could be refactored in such a way that it's not a closure anymore. Then this function could be parameterized on some new trait with a signal_progress method; in the case of native, the trait impl would do nothing; in the wasm case, the impl would actually report progress. This is slightly more involved, but would imply no additional cost for the native case. I didn't look into this before getting any numbers with the suggested approach to confirm that the overhead is an actual issue.
  • implementing threading support for the wasm case. Ahem :-)

Thoughts?