search

blenderskool / vyaakaran

📜 Visualize formal languages and automata
https://vyaakaran.now.sh
MIT License
43 stars 8 forks source link

Explore opportunities for non-UI-blocking processing #7

Open blenderskool opened 2 years ago

blenderskool commented 2 years ago

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.

PochamVarun commented 2 months ago

@blenderskool HI, I am a participant from FOSS Hack, can we please take up this issue. Should we send a proposal for this??

blenderskool commented 2 months ago

@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.

PochamVarun commented 2 months ago

@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.

blenderskool commented 2 months ago

@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 compiler module. If we are able to run the functions exposed by the compiler in context of a web worker, that should work out fine.

Do take a look at libraries like Comlink to make the interfacing with web workers easier. Serializing and Deserializing structures across worker via postMessage calls throughout the codebase can quickly get messy!

PochamVarun commented 2 months ago

Yeah, sure @blenderskool