-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Explore opportunities for non-UI-blocking processing #7
Comments
@blenderskool |
@PochamVarun Yes, it would be great if you can share your approach before you actually work the issue. I would also be able to help and share my thoughts. |
@blenderskool First, I will create a Web Worker Script to isolate core processing logic into a standalone JS file with nesassary functions and logic to handle preprocessing. Then, Create an instance of the web worker on the main JS file and handle communication between the main thread and the worker. Also, add buttons to allow user to start or stop processing to ensure that heavy processing tasks do not block the UI. |
@PochamVarun this approach sounds fine. Most of the core processing logic (which has to be moved in web workers) are already a part of a separate Do take a look at libraries like Comlink to make the interfacing with web workers easier. Serializing and Deserializing structures across worker via |
Yeah, sure @blenderskool |
All the core Vyaakaran processing happens on the main thread which may lead to blocked UI in some heavy and long-running algorithms. Explore ways of moving these algorithm calls to maybe Web Workers which can be physically terminated by the user if they don't prefer waiting.
The text was updated successfully, but these errors were encountered: