Canvas Games Explained

The canvas element is a rectangle with a width, a height and nothing else. No contents, no structure, no meaning. The browser hands the game a drawing context for it, and from that point the game paints pixels into it directly.

Immediate mode

Canvas is immediate mode, which means drawing commands take effect at once and nothing is remembered. There is no list of objects the browser is tracking, no way to ask where the cat is, and no way to move something that has already been drawn.

So moving the cat one pixel right means clearing the entire canvas and drawing the whole scene again in its new position. This sounds wasteful and is in fact extremely fast, because filling a rectangle and drawing shapes is exactly what graphics hardware is built to do.

The contrast is the rest of a web page, which is retained mode: the browser keeps a tree of elements, you change one, and the browser works out what to repaint. That is convenient for documents and far too slow for sixty frames a second of a moving scene.

The clear-and-repaint cycle

1. ClearFill the whole canvas with the background. Skipping this is what produces the smeared-trail effect where the character leaves copies of itself behind.
2. Draw back to frontSky, then distant scenery, then the ground, then obstacles, then the character, then any interface drawn inside the canvas. Order is the only depth control there is.
3. RepeatSixty times a second, or whatever the display's refresh rate is.

That is genuinely the whole rendering model. Everything else is choosing what to draw and where.

Drawing without any images

Every visual on this site's games is drawn from primitives - rectangles, ellipses, lines, paths and gradients. There are no sprite sheets and no image files loading for the game itself.

This has three practical advantages. Nothing needs downloading, so games start instantly. Everything stays crisp at any size, because shapes are drawn at the resolution of the display rather than scaled from a bitmap. And colours can be changed at runtime - the same cat-drawing routine produces an orange cat, a grey night-time cat and a purple wizard cat by passing a different colour.

Handling high-resolution displays

A canvas has two sizes: the number of pixels it contains and the size it is displayed at. On a display with a device pixel ratio of two, a canvas 900 CSS pixels wide needs 1800 actual pixels or everything looks soft.

The standard approach is to set the canvas's pixel dimensions to the CSS size multiplied by the device pixel ratio, then scale the drawing context by the same factor. The game then draws in comfortable logical coordinates and the output is sharp. Capping the ratio at two is usual, because beyond that the extra pixels cost real performance for a difference nobody can see.

The accessibility problem

Because a canvas has no structure, nothing inside it exists as far as assistive technology is concerned. A screen reader encountering a canvas finds an empty box. It does not matter how detailed the drawing is.

This is not a flaw to work around so much as a fact to design for. Anything meaningful has to exist outside the canvas as real HTML:

• Instructions and controls as text on the page, not drawn in the canvas.
• Score, lives and state in real HTML elements that update, so a screen reader can read them.
• An accessible label on the canvas describing what it contains and pointing at the text alternative.
• A live region announcing important state changes such as game over.

Every game page on this site follows that pattern, which is also why the games are indexable: a search engine, like a screen reader, sees only the HTML.

Canvas performance

Canvas is fast, and the ways to make it slow are specific and avoidable.

Changing state constantly

Every fillStyle or font change has a cost. Grouping shapes that share a style is noticeably cheaper than alternating.

Shadows and blur

shadowBlur is by far the most expensive common operation. Using it on a handful of objects is fine; using it on hundreds is not.

Drawing off-screen things

Objects outside the visible area still cost time to process. Culling them is the single easiest optimisation.

Very large canvases

Cost scales with pixel count, and a high device pixel ratio multiplies it. Capping the ratio is worth doing.

Key Takeaways

• Canvas is immediate mode: nothing is remembered, so the whole scene is cleared and repainted every frame.
• Draw order is the only depth control - back to front, every frame.
• Drawing from primitives instead of images means instant loading, crisp scaling and runtime recolouring.
• Scale the canvas by the device pixel ratio, capped at two, or it looks soft on modern displays.
• A canvas is invisible to screen readers and search engines, so everything meaningful must exist outside it in HTML.

Frequently Asked Questions

Why do some canvas games leave trails?

The canvas was not cleared before redrawing. Occasionally it is deliberate as an effect; usually it is a bug.

Is Canvas or WebGL better for 2D games?

Canvas is simpler and fast enough for anything at this scale. WebGL becomes worth the complexity with very large numbers of objects.

Can screen readers read a canvas?

No. The element has no internal structure. Accessible information must be provided in HTML alongside it.

Why does my canvas look blurry?

It is being displayed larger than its pixel dimensions. Scaling by the device pixel ratio fixes it.

Do canvas games work on old devices?

Canvas has been supported for many years. A simple 2D game runs comfortably on hardware that is several years old.