scratchfoundation/scratch-tech-explorations
1
0
Fork 0
mirror of https://github.com/scratchfoundation/scratch-tech-explorations.git synced 2025-08-10 21:08:44 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: sketch a rough plan for this experiment

Browse source
This commit is contained in:
Christopher Willis-Ford 2022-11-18 14:02:51 -08:00
parent 2d80e3c1d9
commit 2d91c97604
1 changed files with 22 additions and 8 deletions

30
README.md
View file

@ -1,12 +1,26 @@
# Scratch Tech Explorations
# Scratch using Tauri+Bevy
This is a repository for sharing tech explorations related to Scratch. Different branches may or may not be related.
If you make a new experiment, try to pick a branch name that hints at what you're exploring. If you make a variant
of an existing experiment, pick a branch name that's related to the existing branch name (unless there's reason not
to).
This branch is for exploring the idea of building a Scratch editor using [Tauri](https://tauri.app/) and
[Bevy](https://bevyengine.org/). The specific proposed architecture:
If you're experimenting with the Scratch 3.0 editor and might want feedback, consider Scratch Lab instead.
## App architecture
Anything here should be treated as experimental, and may or may not be directly used in the future.
* Tauri will display the Scratch UI, analogous to `scratch-gui`, in a web view
* This will also wrap Blockly, the paint editor, and other interactive editor elements
* The web view will include an HTML canvas for the Scratch stage, similar to the current Scratch 3.0 layout
* The stage will be rendered by a small Bevy module compiled to WASM, analogous to `scratch-render`
* Another Bevy module, compiled to native code, will run everything that doesn't interact directly with the stage:
* VM and runtime features similar to `scratch-vm`
* Audio support similar to `scratch-audio`
* Hardware communication for extensions
* etc.
* Communication between the render/web side and native side will be handled through Tauri's IPC-like features
Imagine, program, share!
If Tauri adds support for externally rendering to a canvas (see
[here](https://github.com/tauri-apps/wry/discussions/284)), then the renderer can move to the native side. That should
be even better for performance and should simplify communication as well.
## Web architecture
On the web, all modules will be compiled to WASM and the communication between the rendering module and the rest of
the editor will be more direct. If possible, the rendering and other features should still run in separate threads.