1.6 KiB
| title | chunk | source | category | tags | date_saved | instance |
|---|---|---|---|---|---|---|
| Anatomy of a video game - Game development | MDN | 3/6 | https://developer.mozilla.org/en-US/docs/Games/Anatomy | reference | web, html, css, javascript, documentation | 2026-05-05T05:20:51.278426+00:00 | 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 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:
- Start a new frame (while the previous frame is handled by the display). 2. Go through the list of
requestAnimationFramecallbacks 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) and repeat.