Run Detail

You are a graphics engineer who has spent a lot of time finding out why things are slow.

I want a hundred thousand things moving on screen at sixty frames a second, in one HTML file, with no libraries.

What to build

• A canvas, 900 × 600.
• 100,000 particles, each with its own position and velocity, each one individually updated and drawn every frame.
• They move through a flow field — a smooth, slowly evolving vector field that pushes them around. Curl, drift, eddies. It should look like weather, or ink in water, not like confetti.
• Particles that leave the canvas are recycled back in, so the count never drops.
• The field itself must evolve over time. A static field that particles merely settle into is not what I asked for.

On screen, always visible

• A live FPS readout, honestly measured — a frame-time average, not a number you decided on.
• The particle count, read from the actual data structure holding them, not a constant you typed in the HTML.

House rules

• One file. Everything inline — no CDN, no external stylesheet, font, script or image. data: URIs are fine.
• No libraries. No WebGL helper you paste in. If you want to use WebGL, write it yourself.
• No network at runtime.
• No localStorage, sessionStorage, cookies or indexedDB — sandboxed frame, they throw.
• Return the file as exactly one fenced html block.

Answer in exactly these sections

The plan

One paragraph, before the file. Your data layout, your draw strategy, and the one thing you expect to be the bottleneck.

The file

The single fenced html block.

The prediction

This is the section I care most about. Be specific and commit to numbers:

• FPS I expect on a 2023 laptop, integrated graphics, Chrome — give a single number, not a range wider than about ten.
• Where the time goes — roughly what share is update versus draw, and why.
• The first thing that breaks if I raise the count to a million.
• What you'd need to go ten times faster. Name the technique, not "optimize further".

If you fell short

If you could not do 100,000 at 60fps and shipped fewer, or a cheaper effect than a real flow field, say so here, plainly, and say what you shipped instead. Write Nothing dropped. if you delivered the brief in full.

How this is scored

I am going to open the file and read the FPS counter.

Then I am going to compare it against your prediction. A model that says "about 45fps, fill-rate bound" and measures 43 has understood its own code. A model that says 60 and measures 4 has not, however elegant the code is — and that gap is most of what I am testing here. An honest prediction of a mediocre number beats a confident prediction of a good one.