GraphiteEditor/Graphite

Restructure JS <-> Wasm communication flow and adopt parallelism

Open

#1,113 opened on Apr 11, 2023

View on GitHub
 (3 comments) (0 reactions) (2 assignees)Rust (25,662 stars) (1,176 forks)batch import
Help WantedPerformanceWeb

Description

Right now, JS calls into Wasm, then that calls back into JS again, and that might call back into Wasm, and so on. It does that within the same call stack, so the call stack gets deeper and deeper ping-ponging between the two languages.

We want to flatten this out and build a queue system so either side can queue up tasks. One side processes its queue while building up a queue for the other side, then when done, it switches to the other side and works through its queue on that side, building up tasks for the other side to complete, then it switches again when the queue is done.

We also want to utilize web workers wherever possible to get everything but the DOM manipulations off the main thread, and also benefit where possible from parallelism.

Contributor guide

Tech stack
rustjavascriptwasm
Domain
frontendperformance
Issue type
refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
blocked
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
basic understanding of WebAssemblyJavaScriptparallel programming conceptsRust
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
The issue aims to flatten the nested JS Wasm call stack into a queue system and introduce parallelism using web workers. To understand the current implementation, look at the codebase in the Graphite repository, specifically files handling JS Wasm interop and the rendering pipeline. The issue has two assignees and no open PRs, so check for any linked branches or comments that might provide more context on the planned architecture. The solution likely involves modifying the core loop to switch between processing queues and moving non DOM tasks to web workers.