Skip to content
This repository has been archived by the owner on Oct 28, 2023. It is now read-only.

Signal progress when compiling for wasm32 #153

Closed
bnjbvr opened this issue Nov 14, 2020 · 0 comments
Closed

Signal progress when compiling for wasm32 #153

bnjbvr opened this issue Nov 14, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@bnjbvr
Copy link
Contributor

bnjbvr commented Nov 14, 2020

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?

@bnjbvr bnjbvr added the enhancement New feature or request label Nov 14, 2020
bnjbvr added a commit to bnjbvr/texture-synthesis that referenced this issue Nov 14, 2020
bnjbvr added a commit to bnjbvr/texture-synthesis that referenced this issue Nov 14, 2020
bnjbvr added a commit to bnjbvr/texture-synthesis that referenced this issue Nov 16, 2020
@mergify mergify bot closed this as completed in 4267142 Nov 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant