Reading Apple Pencil Pressure in the Browser — PointerEvent, getCoalescedEvents(), and the e.pressure Trap

Building a sketch pad in a browser sounds like a one-evening job. Then someone tries it with an Apple Pencil and the pressure data is gone, because the code listens for mousemove. Or with a mouse and the line is half as thick as it should be, because it reads e.pressure blindly and a mouse reports 0.5. Or with a fast hand on an iPad and the line is jagged, because the browser only emits one pointermove per 60 Hz frame and the Apple Pencil samples at 240 Hz. This 300-line page solves all three.

🌐 Demo: https://sen.ltd/portfolio/canvas-notebook/
📦 GitHub: https://github.com/sen-ltd/canvas-notebook

Why drop MouseEvent / TouchEvent entirely

The web's input APIs grew in three layers:

• MouseEvent (mousedown / mousemove / mouseup) — mouse only.
• TouchEvent (touchstart / touchmove / touchend) — touch only, multi-finger.
• PointerEvent (pointerdown / pointermove / pointerup) — the unification, plus a stylus story.

PointerEvent carries the type discriminator (e.pointerType ∈ "mouse" / "touch" / "pen") and exposes e.pressure, e.tiltX, e.tiltY, and on some hardware e.twist. One handler, all input devices. It also has setPointerCapture(pointerId), which kills the classic bug where the user drags out of the window and your mousemove handler never sees the release.

The whole input layer of canvas-notebook is three lines of binding plus a few hundred bytes of pointer-id bookkeeping:

els.canvas.addEventListener("pointerdown", onPointerDown);
els.canvas.addEventListener("pointermove", onPointerMove);
els.canvas.addEventListener("pointerup", onPointerUp);
els.canvas.addEventListener("pointercancel", onPointerUp);

e.pressure reports something different on every device

Reading e.pressure and using it as a stroke-width multiplier looks correct. It isn't. The behaviour matrix:

pointerType	what e.pressure returns
mouse	0.5 while a button is held, 0 otherwise
touch (iOS)	force if the OS exposes it (3D Touch's old API is still wired internally)
touch (Android)	typically 0
pen (Apple Pencil)	continuous 0..1, sampled at 240 Hz
pen (Surface Pen / Wacom)	continuous 0..1, 120-240 Hz depending on driver

So if you naïvely write width = baseWidth * e.pressure, mouse strokes come out at half width and Android touch strokes come out at zero (= invisible). The fix is a fallback for pressure === 0:

export function pressureToWidth(pressure, baseWidth, options = {}) {
  const { min = 0.4, max = 1.6, fallback = 0.5 } = options;
  const p = pressure > 0 ? pressure : fallback;
  // [0, 1] → [min, max], clamped, scaled by baseWidth.
  const factor = min + (max - min) * Math.max(0, Math.min(1, p));
  return baseWidth * factor;
}

Three subtleties:

1. Use the fallback only when pressure === 0. A real low-pressure reading like 0.001 is still real data; if you treat anything below 0.05 as the fallback, low-pressure iPad users see their stroke width jump every time they cross the boundary.
2. Clamp out-of-range readings. A handful of buggy drivers report pressure > 1. Don't let that crash your renderer or produce a tree-trunk-thick line.
3. The default band 0.4..1.6 means the stroke is between 40% and 160% of baseWidth end-to-end. The mouse case (pressure === 0 → fallback 0.5 → factor 1.0) lands neatly in the middle of that band, which is what you want.

The unit tests pin the boundaries:

test("pressureToWidth uses fallback only for pressure === 0", () => {
  // 0.001 → real reading, not fallback. Width ends up just above min*base.
  const w = pressureToWidth(0.001, 10);
  assert.ok(w < 10);
  assert.ok(w > 4);
});

test("pressureToWidth clamps out-of-range input", () => {
  assert.equal(pressureToWidth(99, 10), 16);  // capped at max
  assert.equal(pressureToWidth(-1, 10), 10);  // hits fallback path
});

getCoalescedEvents() — the API that exists for exactly this problem

Apple Pencil samples at 240 Hz. The browser's animation frame is 60 Hz. If you read pointermove events at face value, you see one sample per frame, throwing away three out of every four samples the OS captured. Drag fast and the resulting line is a series of long straight chords.

PointerEvent.getCoalescedEvents() gives you back the lost samples — every sub-frame sample that was coalesced into the dispatched event:

function onPointerMove(e) {
  if (state.activePointerId !== e.pointerId) return;

  // Fallback when the API isn't supported or returns an empty list (some
  // synthetic / programmatic events do this).
  let samples = [e];
  if (typeof e.getCoalescedEvents === "function") {
    const coalesced = e.getCoalescedEvents();
    if (coalesced && coalesced.length > 0) samples = coalesced;
  }

  for (const s of samples) {
    state.active.points.push(eventToPoint(s));
  }
  redraw();
}

The screen still only updates at 60 Hz, but the stored stroke data has every sample. PNG / SVG export afterwards has the full 240 Hz fidelity.

The length > 0 guard is real. Synthetic events dispatched via new PointerEvent(...) and dispatchEvent return empty from getCoalescedEvents() in Chromium. Without the fallback, the entire stroke is just the pointerdown and pointerup points and intermediate samples are silently dropped. I burned an hour on this during testing — the fix is the three-line guard.

Ramer-Douglas-Peucker to take the cost back out

240 Hz × a few seconds gives you hundreds-to-thousands of points per stroke. For straight or near-straight segments most of that is redundant. After pointerup we run RDP on the stroke to drop points that lie within tolerance pixels of the chord between their neighbours:

export function simplifyStroke(points, tolerance) {
  if (points.length < 3) return points.slice();
  const t2 = tolerance * tolerance;
  const keep = new Array(points.length).fill(false);
  keep[0] = true;
  keep[points.length - 1] = true;

  function recurse(start, end) {
    let maxDist = 0;
    let idx = -1;
    for (let i = start + 1; i < end; i++) {
      const d = perpendicularDistanceSq(points[i], points[start], points[end]);
      if (d > maxDist) { maxDist = d; idx = i; }
    }
    if (maxDist > t2 && idx !== -1) {
      keep[idx] = true;
      recurse(start, idx);
      recurse(idx, end);
    }
  }
  recurse(0, points.length - 1);
  return points.filter((_, i) => keep[i]);
}

tolerance = 0.4 px is below the resolution of the eye on every realistic display and shrinks the point count by 3-5×. SVG export sizes shrink in proportion. The pressure metadata travels with each kept point — RDP only decides which points survive, not what's on them.

Variable-width rendering, simplest version

Every segment of a stroke gets its own lineWidth, computed from the average of the two endpoint widths:

function drawStroke(stroke, ctx) {
  const pts = stroke.points;
  ctx.strokeStyle = stroke.color;
  for (let i = 1; i < pts.length; i++) {
    const a = pts[i - 1], b = pts[i];
    const wa = pressureToWidth(a.pressure, stroke.baseWidth);
    const wb = pressureToWidth(b.pressure, stroke.baseWidth);
    ctx.lineWidth = (wa + wb) / 2;
    ctx.beginPath();
    ctx.moveTo(a.x, a.y);
    ctx.lineTo(b.x, b.y);
    ctx.stroke();
  }
}

The trick is to set lineCap = "round" and lineJoin = "round" once at canvas init. Each segment ends in a circle of its own width, and adjacent segments overlap by their cap radii. The seams disappear visually.

I tried a fancier version with quadraticCurveTo for path-level smoothing while the lineWidth varied per segment. It does not work. The midpoint-Bézier path-management gets very tricky once you start a new path between every segment, and circular strokes (an "o", a smiley face) end up with gaps. Plain segments + round caps look almost identical and never break.

SVG export's compromise

PNG is one line: canvas.toDataURL("image/png"). SVG has to rebuild the strokes from data:

export function strokesToSvg(strokes, width, height, background = null) {
  const bg = background === null
    ? ""
    : `<rect x="0" y="0" width="${width}" height="${height}" fill="${escapeAttr(background)}"/>`;
  const paths = strokes.map((s) => {
    const d = pointsToSvgPath(s.points);
    const meanWidth = averageWidth(s);
    return `<path d="${d}" fill="none" stroke="${escapeAttr(s.color)}" stroke-width="${fmt(meanWidth)}" stroke-linecap="round" stroke-linejoin="round"/>`;
  }).join("");
  return `<?xml version="1.0" encoding="UTF-8"?><svg ...>${bg}${paths}</svg>`;
}

The compromise: <path stroke-width> is one value per path. There's no SVG primitive for "varying stroke width along a curve" that ships in mainstream renderers. The choices are:

1. Bake the width into the geometry — compute the outline of each variable-width stroke as a polygon, fill it. Faithful to the canvas. 5-10× the bytes.
2. One value per stroke — average the per-point widths and emit stroke-width="<mean>". Loses the within-stroke modulation but keeps file sizes sane.

canvas-notebook ships #2. The PNG export still has the full per-segment widths because Canvas can render them; the SVG is the same drawing at a slightly lower resolution of width information.

The escapeAttr is defensive and tested:

test("strokesToSvg escapes the color attribute against injection", () => {
  const svg = strokesToSvg(
    [{ color: '"><script>', baseWidth: 1, points: [pt(0, 0)] }], 10, 10,
  );
  assert.ok(!svg.includes("<script>"));
  assert.ok(svg.includes("&lt;script&gt;"));
});

The colors come from a fixed picker in the UI, but the test pins the escaping anyway — if the picker ever takes a color from a URL parameter or a saved file, the test catches the regression.

What didn't make the cut

• Per-vertex stroke width in SVG. See above — would inflate file sizes 5-10× by emitting polygon outlines.
• Multi-step undo. One step. A real implementation would store a redo stack of stroke-list snapshots.
• Multiple pages. Single canvas only.
• Background-image annotation. No way to import an image to draw over.
• IndexedDB persistence. Not yet — the canvas is volatile, reload clears it.

Try it

• Demo: https://sen.ltd/portfolio/canvas-notebook/
• Code: https://github.com/sen-ltd/canvas-notebook

If you have an iPad with an Apple Pencil, that's where the pressure story shows up most clearly. On a laptop trackpad or mouse the strokes are still uniform width, but PointerEvent and setPointerCapture and getCoalescedEvents still take care of all the bugs that handlers built on mousemove walk into.

MIT, ~300 lines (notebook.js 200 + script.js 100), 18 unit tests, no build step, zero runtime dependencies.

---

🛠 Built by SEN LLC as part of an ongoing series of small, focused developer tools. Browse the full portfolio for more.