DrftLoadProgress

interface DrftLoadProgress

import type { DrftLoadProgress } from '@driftengine/assets';

In depth

This was not true until it was reported. imagesDone counted an image when its bytes arrived, and the decode that follows is deliberately not awaited so a slow one never holds up the stream. So there was a window in which fraction was 1, every part was uploaded and imagesDone equalled imagesTotal, while the surfaces wearing those images still drew untextured. Measured by a consumer across a scenario switch: one and three quarter seconds.

It cost more than a harness photographing the wrong frame, which is how it was found. The same consumer drives a loading bar off these counters, so the bar reached 100% and the model then visibly changed underneath somebody who had been told it was finished. Their argument for the trade is the one that decided it: a bar that sits still for a moment is honest about being busy, and a bar that finishes early and then lets the thing it loaded change is not, and nobody can tell the second one is happening.

So an image counts when it is on the GPU. fraction reaches 1 when the picture is right, and the cost is that it pauses near the end while the last decodes finish. On a weighted bar that pause is not at 99%: parts and images carry separate shares, so it climbs to roughly two thirds on the uploads and waits there, and a bar that stops at two thirds reads as working where one that stops at 99% reads as stuck.

phase === 'ready' remains the signal to act on, and is what anything judging the finished picture should gate on.

Properties