Your canvas clicks are in the wrong coordinate system

Sat, 10 Oct 2026 19:24:16 +0000

A target at (100, 60) is one quarter across and down a 400 × 240 game. Display the canvas at 800 × 480 CSS pixels and the same target appears at (200, 120) relative to the canvas corner. A pointer handler that compares those CSS coordinates directly with the target will miss it.

At the original display size, the two sets of numbers happened to match. Resizing exposed the missing conversion.

Follow one click through the coordinates

Place the larger canvas at viewport position (100, 50). A click on the target has client coordinates (300, 170):

Subtract the canvas origin: 300 − 100 = 200 CSS pixels across, and 170 − 50 = 120 down.
Divide by the displayed size: 200 / 800 and 120 / 480 both give 0.25.
Multiply by the logical size: 0.25 × 400 = 100 across, and 0.25 × 240 = 60 down.

The fraction carries the position from one set of dimensions to another. If the bitmap is 1600 × 960, the same point is (400, 240) in bitmap pixels. That is useful to a pixel operation, but it is still (100, 60) to the game.

One normalized point expressed in CSS pixels, logical game units and bitmap pixels. Original diagram made with AI-assisted code; the dimensions are chosen examples.

The helper below implements that route for a canvas whose full bitmap fills its content box. It assumes no border, padding, CSS transforms on the canvas or its ancestors, letterboxing, clipped viewport or camera transform. The event and rectangle come from the same document. Use an engine's pointer-to-world API when it already accounts for additional transforms.

function toLogical(
  clientX, clientY, rect,
  width, height
) {
  if (![clientX, clientY,
        rect.left, rect.top,
        rect.width, rect.height,
        width, height]
      .every(Number.isFinite)
      || rect.width <= 0
      || rect.height <= 0
      || width <= 0
      || height <= 0)
    return null;
  const u =
    (clientX - rect.left)
    / rect.width;
  const v =
    (clientY - rect.top)
    / rect.height;
  if (u < 0 || u >= 1
      || v < 0 || v >= 1)
    return null;
  return {
    x: u * width,
    y: v * height
  };
}

On pointerdown, pass event.clientX, event.clientY, a fresh canvas.getBoundingClientRect(), and the logical scene dimensions. Ignore null; otherwise use the returned position for hit testing.

clientX and clientY and getBoundingClientRect() share viewport coordinates. Reading the rectangle at the press accounts for scrolling. Adding a scroll offset—or substituting document-relative pageY—would mix coordinate systems again.

The helper includes the left and top edges and rejects the right, bottom and outside. It does not clamp a gutter click onto an edge target. Keep fractional results for logical hit testing.

Density belongs on the drawing side

Increasing bitmap density can sharpen the canvas without moving the target in the game. devicePixelRatio relates physical pixels to CSS pixels and can change with zoom or a different display. Multiplying the helper's output by DPR would apply a second, unwanted conversion.

For the 400 × 240 logical scene, use ctx.setTransform(canvas.width / 400, 0, 0, canvas.height / 240, 0, 0) when drawing. The actual integer bitmap dimensions account for resize rounding. setTransform replaces the scale rather than compounding it on each resize.

Keep CSS size independent of the bitmap attributes, for example with an explicit width and aspect ratio. Otherwise enlarging canvas.width can enlarge an intrinsically sized element too. Assigning canvas.width resets the context, so restore the transform and drawing styles afterward. Handle density changes even when the element's CSS size stays the same.

An iframe can resize correctly while clicks remain wrong

Rosebud's November 2024 embedding guide describes responsive iframe sizing. That handles the outer display; the pointer conversion still belongs to the document containing the canvas. Host-page coordinates cannot be paired with an inner canvas rectangle, and same-origin restrictions limit cross-origin access.

A correctly sized embed is therefore a place to repeat the target test, not evidence that the game's input handler is correct. First verify the arithmetic with the helper above:

const wide = {
  left: 100, top: 50,
  width: 800, height: 480
};
console.log(toLogical(
  300, 170, wide, 400, 240
)); // {x: 100, y: 60}
const small = {
  ...wide,
  width: 400, height: 240
};
console.log(toLogical(
  200, 110, small, 400, 240
)); // {x: 100, y: 60}
console.log(toLogical(
  900, 170, wide, 400, 240
)); // null: right edge

Then click that same target at two display sizes in the real delivery page, scroll, and try the edges and gutter. If the arithmetic passes but those presses fail, compare the measured content area with the helper's layout assumptions—especially borders, letterboxing and transforms.

Coder Legion - Recent posts tagged browser-games

Your canvas clicks are in the wrong coordinate system

Follow one click through the coordinates

Density belongs on the drawing side

An iframe can resize correctly while clicks remain wrong