State of the art tooling for 4k intro for the Web
category: code [glöplog]
Lastly, I am not liking the standard SVG+fetch() packing system. Depending on Cache-Control and other factors, it will actually require downloading the demo twice. I think this makes the idea of “very few bytes can do a lot of content” a bit harder to sell, because you have to make it about the "bytes used to store the demo on the server's disk" instead of "bytes you had to download to see watch the demo". Basically, when you open the Networking panel on your browser, the SVG method feels a bit like cheating.
So I explored other deliveries methods:
* Direct BR/GZ tranmission through HTTP, makes the demo watchable with a single query, potentially halving the number of bytes down the wire. It still does require a server, although if you happen to have the file on disk, it’s easy enough to just right click and decompress it with your OS’s default ZIP utility.
* A Base222 self-contained HTML, which is also playable with a single HTTP request, and can also run serverless by just drag-and-dropping the file to a browser if you have it on disk. It’s a bit bigger on the wire (and disk) since the encoding is not as efficient.
You can argue that unlike the SVG method which relies on Web APIs only, the BR/GZ method depend on HTPP since it does requires Content-Encoding gzip headers for the intro to be compressed. I'd argue the SVG method can only make fair claims about download sizes if there are proper Cache-Control headers anyways, so to me both play on a plain field really. Both require a server for delivery, but BR/GZ is guaranteed to send the true bytes once.
Both SVG and BR/GZ still require a server, though BR/GZ is a bit more friendly if you have the intro on disk and just want to watch it without launching a server. But the only true serverless solution is the Base222 one.
In summary:
With all this in mind, does you think size coding for the Web should be about "bytes on (the server's) disk" (SVG and Base222) or about "bytes to download" (BR/GZ and Base222) ???
So I explored other deliveries methods:
* Direct BR/GZ tranmission through HTTP, makes the demo watchable with a single query, potentially halving the number of bytes down the wire. It still does require a server, although if you happen to have the file on disk, it’s easy enough to just right click and decompress it with your OS’s default ZIP utility.
* A Base222 self-contained HTML, which is also playable with a single HTTP request, and can also run serverless by just drag-and-dropping the file to a browser if you have it on disk. It’s a bit bigger on the wire (and disk) since the encoding is not as efficient.
You can argue that unlike the SVG method which relies on Web APIs only, the BR/GZ method depend on HTPP since it does requires Content-Encoding gzip headers for the intro to be compressed. I'd argue the SVG method can only make fair claims about download sizes if there are proper Cache-Control headers anyways, so to me both play on a plain field really. Both require a server for delivery, but BR/GZ is guaranteed to send the true bytes once.
Both SVG and BR/GZ still require a server, though BR/GZ is a bit more friendly if you have the intro on disk and just want to watch it without launching a server. But the only true serverless solution is the Base222 one.
In summary:
Code:
Method On Disk On HTTP Page Source Serverless
======= ======= ======= =========== ==========
SVG 4987 9974 4987 No
BR/GZ 4865 4865 6548 No/Kindof
Base222 5284 5284 5284 YesWith all this in mind, does you think size coding for the Web should be about "bytes on (the server's) disk" (SVG and Base222) or about "bytes to download" (BR/GZ and Base222) ???
Nice!
Have you tried ECT instead of Zopfli ?
It gave better results in my recent tests.
For quick and dirty experimentation purpose on Elevated: Throwing the source code at Claude, instructed to use terser, roadroller, ECT, the SVG loader, .... came at 5,217 bytes at first. Iterating a bit, without sacrificing the audio or visuals, came down to 4,928 and 4,937 depending if the audio generated at first or live.
So yeah, in the 4.8-4.9 Kb ballpark, or ~1.2x the size of native, which matches pretty closely my experience in 1kb intros.
Have you tried ECT instead of Zopfli ?
It gave better results in my recent tests.
Quote:
😮 Wowzers!modified version of Roadroller that Blueberry created, which saved 200 bytes.
For quick and dirty experimentation purpose on Elevated: Throwing the source code at Claude, instructed to use terser, roadroller, ECT, the SVG loader, .... came at 5,217 bytes at first. Iterating a bit, without sacrificing the audio or visuals, came down to 4,928 and 4,937 depending if the audio generated at first or live.
So yeah, in the 4.8-4.9 Kb ballpark, or ~1.2x the size of native, which matches pretty closely my experience in 1kb intros.
About bytes on disk or served, the second request should be cached so zero bytes actually transfered.
The Web requires a server.
A few things work from file:// as a convenience, but the Web is the Web, so there should be no controversy for Web prods to need a server, even if only to serve the proper headers.
The Web requires a server.
A few things work from file:// as a convenience, but the Web is the Web, so there should be no controversy for Web prods to need a server, even if only to serve the proper headers.
I tried ECT, Zopfli and Turtle, but Zopfli worked best for me.
Damn, I could have a whole weeks of work :(
Quote:
For quick and dirty experimentation purpose on Elevated: Throwing the source code at Claude, instructed to use terser, roadroller, ECT, the SVG loader, .... came at 5,217 bytes at first. Iterating a bit, without sacrificing the audio or visuals, came down to 4,928 and 4,937 depending if the audio generated at first or live.
Damn, I could have a whole weeks of work :(
* I could have saved a whole week
Quote:
Ah! I only tried ECT recently, and just learnt about Turtle. But then I will definitely try the 3 of them next time I work with Deflate.I tried ECT, Zopfli and Turtle, but Zopfli worked best for me.
Quote:
I could have saved a whole week
"Saved".
Instead you learnt a ton in that week about how these tools work with each other.
FWIW, as plain html.br it goes down to 4,595 and 4,612 depending if the audio is generated first or live. That's roughly 1.125x from native.
Quote:
With all this in mind, does you think size coding for the Web should be about "bytes on (the server's) disk" (SVG and Base222) or about "bytes to download" (BR/GZ and Base222) ???
muhmac (and later used by Bercon, in Incendium) packed Brotli compressed intro into a Powershell script. When the script is ran, it acts as a tiny web server, opens a browser pointing to the local url, and serves the intro as a .br compressed stream. This gives an intro that can be executed locally; does not need wanky browser security settings; is <= 4k on disk; and uses Brotli for compression; all without requiring DecompressionStream('brotli').
Powershell bootstrap code costs bytes though:
https://github.com/Bercon/incendium/blob/16c14f83ce7ad2d4436bdb157a58793200530003/scripts/packager/compress.py#L15
I used Incendium as one of the test cases for the modified Roadroller. It came out slightly ahead of the PowerShell+brotli version, with 4057 against 4093.
To me the appeal of 'web' intros is that they're fully cross-platform, so having the Powershell dependency feels a bit antithetical. But I guess you could say that dropper would only be used for the compo, perhaps.
