---
title: "Anatomy of a video game - Game development | MDN"
chunk: 3/6
source: "https://developer.mozilla.org/en-US/docs/Games/Anatomy"
category: "reference"
tags: "web, html, css, javascript, documentation"
date_saved: "2026-05-05T05:20:51.278426+00:00"
instance: "kb-cron"
---

The above sections describe main loops that avoid taking control away from the browser. These main methods attach themselves to `window.requestAnimationFrame()`, which asks the browser for control over the upcoming frame. It is up to the browser how to relate these requests to its main loop. The [HTML spec](https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#dom-animationframeprovider-requestanimationframe) does not really define exactly when the browsers must perform the `requestAnimationFrame` callbacks. This can be a benefit because it leaves browser vendors free to experiment with the solutions that they feel are best and tweak them over time. Modern versions of Firefox and Google Chrome (and probably others) _attempt_ to connect `requestAnimationFrame` callbacks to their main thread at the very beginning of a frame's timeslice. The browser's main thread thus _tries_ to look like the following:
  1. Start a new frame (while the previous frame is handled by the display). 2. Go through the list of `requestAnimationFrame` callbacks and invoke them. 3. Perform garbage collection and other per-frame tasks when the above callbacks stop controlling the main thread. 4. Sleep (unless an event interrupts the browser's nap) until the monitor is ready for your image ([VSync](https://en.wikipedia.org/wiki/Screen_tearing#Vertical_synchronization)) and repeat.