mirror of
https://github.com/tiennm99/rplace.git
synced 2026-10-11 03:13:48 +00:00
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.
2.0 KiB
2.0 KiB
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
-
Edit
src/lib/constants.js:export const CANVAS_WIDTH = 8192; // was 4096 export const CANVAS_HEIGHT = 8192; // was 4096TOTAL_PIXELSandCHUNK_COUNTrecompute automatically. Bumping to8192×8192raisesCHUNK_COUNTfrom 256 to 1024 (still well under the 1 GB single-DO limit, which would allow ~32K×32K). -
Build and deploy:
npm run deploy -
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 runDELETE 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_BYTEShas 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.