Confirmed a demo script created on 2022-07-06 yields logs as above.
Source of these
Naïve plan — Drop-and-Replace
What if we drop-and-replace
postViaSab that follows the same interface as
postMessage but is internally made with SharedArrayBuffer.
Wouldn't this yield much higher throughput? (No, it wouldn't.)
Shortcomings of SharedArrayBuffer
- Fixed in Size
Currently, WorkerDOM only has asynchronous data channels. WorkerDOM batch processes requests between agents (i.e., it collects operations and sends them at once.) WorkerDOM will have Scheduler support for general tasks, extended tasks, etc. What kinds of data channels does WorkerDOM have?
Would it be efficient to change all asynchronous data channels to synchronous SharedArrayBuffer?
In easy words, Brane implements a premium-tier SharedArrayBuffer fast lane that will handle priority tasks. It might block user interaction because SharedArrayBuffer is synchronous. This is why we need a proper Scheduler.
Priority: ① User Interaction ② Layout Operations ③ Other Operations
The reason for such SharedArrayBuffer is to eradicate any compatibility issues.
For example, one incompatible operation is
This calculation must process in a blocking condition.
This blocking condition must happen in SharedArrayBuffer.
WorkerDOM cannot handle animation libraries because it lacks synchronous API support.
- Synchronous XMLHttpRequest.
notify()for blocking constructs.
- Replace all unofficial implementation of
getClientBoundingRectin WorkerDOM with
- Geolocation might be easier, because it is an asynchronous API.
- The hard part is transports and schedulers.
- Better Docusaurus
- Fortune Cookie: Collaborate with those who possess both intelligence and integrity.