Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,8 @@ The goal is simple: make this the best community drawing engine for React Native

mobile-ink is currently used in production in MathNotes: https://apps.apple.com/us/app/mathnotes-ai-notes-for-stem/id6751956086

[Four Engines in Nine Months](https://medium.com/@markmiller0470/four-engines-in-nine-months-what-it-actually-takes-to-build-a-performant-notebook-app-8cc3f6cf9bfc) is the engineering story behind this engine: the three drawing stacks that failed before this one, and what it cost to make ink, memory, zoom, and long notebooks work together.

## Why Not Just Use Skia, PencilKit, Or A Web Canvas?

Most drawing tools give you a place to capture or render ink. They do not give you the continuous notebook surface that makes a real notes app hard: page pooling, long-document scrolling, zoom, selection, serialization, previews, native memory pressure handling, and cross-platform behavior.
Expand Down Expand Up @@ -180,6 +182,7 @@ The Android example runs the drawing canvas path. The benchmark screen and CPU/G
- [Architecture](docs/architecture.md)
- [API Reference](docs/api.md)
- [Changelog](CHANGELOG.md)
- [Four Engines in Nine Months](https://medium.com/@markmiller0470/four-engines-in-nine-months-what-it-actually-takes-to-build-a-performant-notebook-app-8cc3f6cf9bfc) - engineering write-up on stroke geometry, native memory, zoom, and page pooling

## Roadmap

Expand Down
2 changes: 2 additions & 0 deletions docs/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,8 @@ The C++ layer owns high-frequency drawing behavior: active stroke rendering, pat

`ContinuousEnginePool` defaults to three engines. During viewport movement, the transform stays on the UI thread. When motion settles, the pool assigns engines around the settled page. Dirty pages are serialized before a pooled engine is reused for another page.

Virtualizing native canvases the way a list virtualizes rows does not work here: creating and destroying GPU contexts mid-scroll contends with the thread presenting frames, so every page crossing becomes a stutter. Pooling a fixed set of engines and moving page assignment between them is what keeps allocations flat during long-document scrolling. [Four Engines in Nine Months](https://medium.com/@markmiller0470/four-engines-in-nine-months-what-it-actually-takes-to-build-a-performant-notebook-app-8cc3f6cf9bfc) walks through the approaches that failed first and the settle-handoff behavior that hides engine load time.

## Serialization

A `SerializedNotebookData` payload is plain JSON:
Expand Down
Loading