Real transferred-byte progress for a real origin - a server, a dev server, or a desktop
host serving through a virtual origin rather than raw file:// (see desktop/'s own
SetVirtualHostNameToFolderMapping for why that distinction matters). This is deliberately
separate from load's own AssetProgress: that one reports a fraction of assets finished
because, as its own doc comment says, "Pixi's own loaders do not expose bytes transferred
across every asset type uniformly" - reporting a number this project cannot actually back
would be exactly the kind of silent-fallback dishonesty this project's own conventions rule
out elsewhere. fetch() itself is blocked from file:// entirely, so calling this from a
compiled data-URI build throws the same way any other fetch() there would; it exists for
item 137's "a server or standalone WebView2/Chromium host can stream/cache assets
incrementally and report byte progress" capability tier, not the file:// one.
Real transferred-byte progress for a real origin - a server, a dev server, or a desktop host serving through a virtual origin rather than raw
file://(seedesktop/'s ownSetVirtualHostNameToFolderMappingfor why that distinction matters). This is deliberately separate fromload's ownAssetProgress: that one reports a fraction of assets finished because, as its own doc comment says, "Pixi's own loaders do not expose bytes transferred across every asset type uniformly" - reporting a number this project cannot actually back would be exactly the kind of silent-fallback dishonesty this project's own conventions rule out elsewhere.fetch()itself is blocked fromfile://entirely, so calling this from a compiled data-URI build throws the same way any otherfetch()there would; it exists for item 137's "a server or standalone WebView2/Chromium host can stream/cache assets incrementally and report byte progress" capability tier, not thefile://one.