Coder Legion - Recent posts tagged canvas

Canvas cropping: keep source pixels separate from output size

Sat, 17 Oct 2026 06:37:13 +0000

A crop box and an export size describe two different things. The crop box chooses pixels from the decoded source; the export size decides how many pixels to write. Keeping those numbers separate makes an image editor much easier to reason about.

Start with image pixels, not the preview rectangle

Suppose the decoded image is 320 × 240 pixels. You want the region beginning at (40, 24), with a width of 200 and a height of 160. That rectangle fits because 40 + 200 <= 320 and 24 + 160 <= 240.

The preview might be displayed at half size. In that case, a pointer position of 20 CSS pixels from its left edge represents 40 source pixels. Convert pointer coordinates using the actual displayed image rectangle before storing the crop. If the image is letterboxed inside a larger container, use the image rectangle rather than the container, or subtract the padding first.

For an image drawn without rotation, the conversion is:

const sourceX = (pointerX - imageRect.left) * source.width / imageRect.width;
const sourceY = (pointerY - imageRect.top) * source.height / imageRect.height;

Clamp the final rectangle to the source bounds and choose an explicit rounding rule. Do not let a partially outside selection silently become an unexpected export.

Pass both rectangles to Canvas

The nine-argument form of drawImage keeps the two jobs visible. For that 200 × 160 crop, a 500 × 400 export preserves the 5:4 aspect ratio:

canvas.width = 500;
canvas.height = 400;
ctx.drawImage(source, 40, 24, 200, 160, 0, 0, 500, 400);

The first rectangle belongs to the source image. The second belongs to the destination canvas. Setting the canvas bitmap dimensions matters: changing only its CSS width changes the preview, not the exported pixel dimensions.

Validate that the dimensions are positive and the crop fits the decoded image. Also apply a pixel budget before allocating a large canvas. A very long, narrow image and a square image can have the same pixel count but different side-length constraints, so check both.

Encode the result, then inspect it

Export through canvas.toBlob, handle a null result, and check the returned type. For PNG, the browser can preserve transparency. JPEG is useful when a photographic image needs a smaller raster file, but a quality setting does not change the crop geometry. When decoding an external URL, its cross-origin policy can affect whether the canvas is exportable; a local file selected by the user avoids that particular remote-origin workflow.

Keep SVG tracing as a separate decision

Resizing a raster image does not turn its pixels into vector paths. Tracing is another step, with choices about color detail and smoothing. For a flat-color motif, crop away irrelevant borders first, trace it, and compare the original and vector preview at more than one zoom level. Look at small gaps, corners and separate color regions before downloading.

A useful no-setup way to explore that sequence is the browser image workspace in JPG to SVG: crop or resize a local image, then send it to tracing without selecting the file again. Processing stays in the browser, and the SVG output contains paths. I help maintain the product.

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.

Freehand drawing with the Canvas API

Thu, 08 Oct 2026 02:55:43 +0000

When I was trying Canvas, I was completely puzzled. It felt so frustrating; I felt like I was writing in a completely different language instead of my usual JavaScript. But after reading the MDN doc and watching some videos...it still feels difficult and frustrating. But despite everything, let's try to build something. Polishing can come later.

First, we need to select the ID from HTML

const canvas = document.querySelector("#draw");

We need canvas.getContext here to tell the browser what type of drawing we are going to do. For now, the screen is blank, so we need to tell it what we are going to do. The <canvas> element has a method called getContext. That's the one we are targeting here

const ctx = canvas.getContext("2d");

We are going to draw on the whole window, so we need to target the whole window. But we can't just let HTML decide the window. We need to overwrite it, and JavaScript can help here with its innerHeight and innerWidth properties

canvas.width = window.innerWidth;
canvas.height = window.innerHeight;

That's a lot. I know. So, let's slow down and draw our first rectangle.

function draw() {
  const canvas = document.querySelector("#draw");
  const ctx = canvas.getContext("2d");

  ctx.fillStyle = "rgb(200 0 0 / 50%)"; // setting the rect color with the fillStyle property
  ctx.fillRect(10, 10, 50, 50); // drawing the rectangle using the fillRect canvas api's method
}
draw();

That was easy, but we are not going to draw shapes. Our goal is to use freehand. Comment out or delete the previous draw function.

For now, we need four things before going forward. Set the color of the pen, how we want our pen to be, how the ends of lines look, and the size of the pen.

ctx.strokeStyle = "rgb(200 135 90)";
ctx.lineJoin = "round";
ctx.lineCap = "round";
ctx.lineWidth = 5;

Here we can set the pen color with strokeStyle, how corners between connected lines look with lineJoin, the ending of the lines with lineCap (default to butt), and the size with lineWidth.

We don't want to draw with every movement our mouse do. Only when we click the mouse and move it. So here it is

let isDrawing = false;

let lastX = 0;
let lastY = 0;

lastX/Y start at 0 as a placeholder. Later, they get replaced by the real mouse X/Y position from e.offsetX/Y.

Let's draw it now:

function draw(e) {
  if (!isDrawing) return;
  console.log(e);
  ctx.beginPath();
  ctx.moveTo(lastX, lastY);
  ctx.lineTo(e.offsetX, e.offsetY);
  ctx.stroke();
  [lastX, lastY] = [e.offsetX, e.offsetY];
}

The condition prevents drawing when the mouse button is not being held down
beginPath() starts a new path every time
moveTo() sets the starting point of the line
lineTo() draws a line from the current point to the current mouse position
stroke() draws the path onto the canvas using the current stroke settings
[lastX, lastY] = [e.offsetX, e.offsetY] updates to the current mouse position by destructuring

// Mouse button pressed down → start drawing
canvas.addEventListener("mousedown", (e) => {
  isDrawing = true;
  [lastX, lastY] = [e.offsetX, e.offsetY];
});

// Mouse button released → stop drawing
canvas.addEventListener("mouseup", () => {
  isDrawing = false;
});

// Mouse leaves canvas → also stop
canvas.addEventListener("mouseout", () => {
  isDrawing = false;
});

// Mouse moves → only draw if the flag is true
canvas.addEventListener("mousemove", draw);

That's it for today. Tada! Leave a comment if you want to.