Enable ArrayBuffer Transfer via postMessage for Improved Performance
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- frontend
Research direction
Locate the UseWebViewResult definition and trace the existing postMessage forwarding path into the WebView. Update the interface and forwarding path so an optional Transferable[] is accepted and attached to the message; done means ArrayBuffer data is usable in the WebView without base64 conversion.
Written by the indexing model from the issue text.
Description
TLDR;
Currently, passing ArrayBuffer data from Devvit to a WebView requires converting it to a base64 string. This workaround significantly increases data size and reduces performance due to unnecessary cloning and data encoding.
Description:
Forwarding raw arrayBuffer received with a fetch request from devvit to the Webview is a great performance improvement, currently the only workaround is to convert data as a base 64 string, which clones and expand the data size.
Transferable objects are commonly used to share resources that can only be safely exposed to a single JavaScript thread at a time. For example, an ArrayBuffer is a transferable object that owns a block of memory. When such a buffer is transferred between threads, the associated memory resource is detached from the original buffer and attached to the buffer object created in the new thread.
The correct solution would be to forward the third argument of postMessage function:
transfer
An optional array of transferable objects to transfer ownership of. The ownership of these objects is given to the destination side and they are no longer usable on the sending side. These transferable objects should be attached to the message; otherwise they would be moved but not actually accessible on the receiving end.
Today, passing an arrayBuffer via postMessage will make it not accessible from within the Webview for the reason above.
The solution would be to change the signature of the postMessage function in UseWebViewResult from:
postMessage(message: To): void;
to:
postMessage(message: To, transfer?: Transferable[]): void;
- Dominant language
- TypeScript
- Stars
- 210
- Forks
- 88
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from reddit/devvit
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 42/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fullcalendar/fullcalendar#8106 ·