@groundcover/browser 2.1.0-rc.1 → 2.1.0

package/CHANGELOG.md

@@ -4,37 +4,37 @@ All notable changes to `@groundcover/browser` are documented here. This project
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and the
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format.
 
-## [2.1.0-rc.1] — 2026-10-07
+## [2.1.0] — 2026-10-12
 
-Second release candidate of `2.1.0`. Tunes canvas capture's default from measurements; nothing
-changes unless `options.replay.canvas.enabled` is set.
+Stable release of the `2.1.0-rc.0` and `2.1.0-rc.1` line. Adds opt-in canvas capture to session
+replay; nothing changes unless `options.replay.canvas.enabled` is set. No breaking changes from
+`2.0.0`.
 
-### Changed
-
-- **`replay.canvas.fps` defaults to 1** (was 4). rrweb re-encodes every canvas on every tick whether
-  or not it changed, so the rate drives CPU even on a static page, while bytes grow only when content
-  changes. On a six-chart test dashboard, 1 fps used about 12% of a CPU core against about 35% at
-  4 fps, with the same bytes. Set `fps` explicitly for animated canvases.
-- **README: canvas capture recipes** for dashboards, animated canvases, constrained bandwidth and
-  CPU-sensitive pages, with measured costs for scale.
-
-## [2.1.0-rc.0] — 2026-10-06
-
-First release candidate of `2.1.0`, on top of `2.0.0`. Adds opt-in canvas capture to session replay;
-nothing changes unless `options.replay.canvas.enabled` is set.
+The shipped JavaScript (`index.js`, `index.mjs` and the replay worker) is byte-for-byte rc.1's. The
+type declarations differ from rc.1 only in the `replay.canvas.fps` doc comment. Against `2.0.0`, the
+declarations add `ReplayCanvasOptions` and the optional `replay.canvas` field, and the exported types
+are otherwise unchanged.
 
 ### Added
 
 - **Session replay can capture `<canvas>`-rendered content** (e.g. chart data series that replayed
   as empty frames) via `options.replay.canvas`. Off by default. `enabled` maps to rrweb
-  `recordCanvas`, `fps` (default 4, clamped to 1–15 with a warning) to `sampling.canvas`, and
+  `recordCanvas`, `fps` (default 1, clamped to 1–15 with a warning) to `sampling.canvas`, and
   `imageType` / `imageQuality` (default `image/webp` at 0.6) to `dataURLOptions`. Canvas frames are
   pixel snapshots: they increase replay bandwidth and page CPU, and are **not** covered by `privacy`
   text/input masking. WebGL capture is best-effort only (the page's context must use
   `preserveDrawingBuffer: true`).
+- **`fps` sets CPU cost and time resolution, not bytes.** rrweb re-encodes every canvas on every
+  tick whether or not it changed, so the rate drives CPU even on a static page; a frame identical to
+  the previous one is dropped, so bytes grow only when content changes. On a six-chart test
+  dashboard, 1 fps used about 12% of a CPU core against about 35% at 4 fps, with the same bytes. A
+  canvas state shorter than `1/fps` seconds may not appear in the replay, so raise `fps` for
+  animated canvases.
 - **Changing `replay.canvas` through `updateConfig` restarts the active recording**, like
   `replay.blockedSelectors` and `privacy`. A partial update merges into the current canvas options,
   so `{ canvas: { fps: 8 } }` keeps capture enabled.
+- **README: canvas capture recipes** for dashboards, animated canvases, constrained bandwidth and
+  CPU-sensitive pages, with measured costs for scale.
 
 ### Fixed
 

package/README.md

@@ -242,6 +242,11 @@ redraw. Start from the closest recipe and adjust:
 | Constrained bandwidth | `{ enabled: true, imageQuality: 0.3 }` plus `replay.blockedSelectors` | Lower quality shrinks each image; blocked canvases are skipped entirely. |
 | CPU-sensitive pages (low-end devices) | `{ enabled: true, imageType: "image/png" }` | PNG encodes much faster than webp but produces about twice the bytes. |
 
+Capture samples each canvas every `1/fps` seconds and drops a frame that's identical to the
+previous one, so an unchanged canvas sends nothing between full snapshots. The sampling also sets
+the time resolution: a canvas state that lasts less than `1/fps` seconds, such as a brief transition
+or a hover highlight, may not appear in the replay. Raise `fps` when those moments matter.
+
 For scale, on a test dashboard with six canvas charts on a 2× display, canvas capture added about
 280 KB/min while the charts were static and about 1 MB/min while they refreshed every 10 s. The
 recorder used about 12% of a CPU core at 1 fps and about 35% at 4 fps, with the same bytes. PNG at

package/dist/index.d.mts

@@ -346,8 +346,11 @@ interface ReplayCanvasOptions {
      * Snapshot frame rate, in frames per second. Defaults to 1 and is clamped to
      * [1, 15]; out-of-range values are clamped with a `console.warn`. Maps to
      * rrweb's `sampling.canvas`. Every canvas is re-encoded on every tick, so a
-     * higher rate costs CPU even when nothing changes; it adds bytes only for
-     * canvases that change faster than the rate. Raise it for animated canvases.
+     * higher rate costs CPU even when nothing changes; frames identical to the
+     * previous one are dropped, so it adds bytes only for canvases that change
+     * faster than the rate. The rate is also the time resolution: a canvas state
+     * shorter than `1/fps` seconds (a brief transition or hover highlight) may not
+     * appear in the replay. Raise it for animated canvases.
      */
     fps?: number;
     /**

package/dist/index.d.ts

@@ -346,8 +346,11 @@ interface ReplayCanvasOptions {
      * Snapshot frame rate, in frames per second. Defaults to 1 and is clamped to
      * [1, 15]; out-of-range values are clamped with a `console.warn`. Maps to
      * rrweb's `sampling.canvas`. Every canvas is re-encoded on every tick, so a
-     * higher rate costs CPU even when nothing changes; it adds bytes only for
-     * canvases that change faster than the rate. Raise it for animated canvases.
+     * higher rate costs CPU even when nothing changes; frames identical to the
+     * previous one are dropped, so it adds bytes only for canvases that change
+     * faster than the rate. The rate is also the time resolution: a canvas state
+     * shorter than `1/fps` seconds (a brief transition or hover highlight) may not
+     * appear in the replay. Raise it for animated canvases.
      */
     fps?: number;
     /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groundcover/browser",
-  "version": "2.1.0-rc.1",
+  "version": "2.1.0",
   "description": "groundcover Real User Monitoring (RUM) SDK for the browser \u2014 performance, errors, logs, distributed tracing and session replay",
   "main": "dist/index.js",
   "module": "dist/index.mjs",