mirror of
https://github.com/tiennm99/rplace.git
synced 2026-10-11 03:13:48 +00:00
tiennm99
cdf2295ef6
Earlier docs assumed a 1 GB per-DO storage cap. Actual May 2026 free-tier limits per the CF DO docs: - 10 GB per Durable Object - 5 GB per account (the real Free-tier ceiling) - 2 MB per BLOB row - 1,000 req/sec soft cap per DO Practical effect: canvas can grow to ~70,000 × 70,000 on Free (was previously documented as ~32K × 32K). Existing 64 KB CHUNK_BYTES is well-suited: clustered writes (single pixels + image patches) minimize read-modify-write amplification; bigger chunks would only help uniform-random writes which isn't rplace's workload. No code change. Just doc accuracy.
57 lines
2.0 KiB
Markdown
57 lines
2.0 KiB
Markdown
# Canvas Resize Procedure
|
||
|
||
The canvas dimensions are driven by two constants. Storage chunks auto-derive,
|
||
so resizing is a config change followed by a redeploy — no migration code
|
||
needed.
|
||
|
||
## Steps
|
||
|
||
1. Edit `src/lib/constants.js`:
|
||
|
||
```js
|
||
export const CANVAS_WIDTH = 8192; // was 4096
|
||
export const CANVAS_HEIGHT = 8192; // was 4096
|
||
```
|
||
|
||
`TOTAL_PIXELS` and `CHUNK_COUNT` recompute automatically. Bumping to
|
||
`8192×8192` raises `CHUNK_COUNT` from 256 to 1024 (still well under the
|
||
1 GB single-DO limit, which would allow ~32K×32K).
|
||
|
||
2. Build and deploy:
|
||
|
||
```bash
|
||
npm run deploy
|
||
```
|
||
|
||
3. The DO lazy-initializes any missing chunks on the next read. New
|
||
bytes are zero-filled (palette index 0 — pure black). Existing pixels
|
||
keep their `(x, y)` coordinates; the canvas just becomes larger around
|
||
them.
|
||
|
||
## Caveats
|
||
|
||
- **Shrinking** the canvas leaves orphan chunk rows past the new
|
||
`CHUNK_COUNT`. Existing reads are unaffected (they only iterate up to
|
||
the new limit), but storage usage stays high until they're cleaned up.
|
||
To reclaim: connect to the DO and run
|
||
`DELETE FROM canvas_chunks WHERE chunk_id >= NEW_CHUNK_COUNT`.
|
||
- **Aspect ratio change** (non-square) is fine. The 1-D byte-layout
|
||
(`y * CANVAS_WIDTH + x`) still holds. Just make sure clients pull
|
||
the new constants too — frontend reads them from the same module.
|
||
- **Storage caps (Cloudflare Free plan, 2026).**
|
||
- Per Durable Object: **10 GB** (would allow ~100,000 × 100,000)
|
||
- Per Account: **5 GB** (the real ceiling on Free)
|
||
- At 1 byte per pixel, the practical free-tier ceiling is roughly
|
||
**70,000 × 70,000 pixels** (≈4.9 GB).
|
||
- SQLite BLOB row cap is **2 MB**; our 64 KB `CHUNK_BYTES` has 32× headroom
|
||
so resizing never touches that limit.
|
||
|
||
## Free-tier monitoring
|
||
|
||
After resize, watch:
|
||
- Cloudflare Workers requests/day (free cap: 100,000)
|
||
- Durable Object storage (free caps: 10 GB per DO, 5 GB per account)
|
||
- Per-DO request rate (soft cap: 1,000 req/sec)
|
||
|
||
All visible on the Cloudflare dashboard for the rplace project.
|