dassurma

I am not! I have no styles that should affect scrollbar visibility. What browser & OS are you on?

The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.

You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)

Hi! Squoosh team lead here :)

What kind of explanation would you like to see? We link to the repo and the Privacy explainer at the bottom of the page. Why is it important to you to know that it’s made by Googlers?

The thing with GIF is that it’s rarely better than a paletted PNG.

As for animations, video formats with a very low fps are usually way better suited and smaller than GIFs.

The goal of Squoosh is more to teach out about all the options and levers codecs have. JPEG is not “suggested”, it’s just literally the first codec we ported to Wasm so that’s the auto-selected one :D

The Squoosh CLI has an auto-optimizer that will make an image as small as possible while staying under a given Butteraugli threshold, but you still have to decide on the format yourself.

https://github.com/GoogleChromeLabs/squoosh/tree/dev/cli

<3

Do you mean serve the app from an S3 bucket? It’s a fully static site without any server-side components, so go nuts.

If you mean compress all images in an S3 bucket? Not directly. But we do have a Squoosh CLI!

https://github.com/GoogleChromeLabs/squoosh/tree/dev/cli

The difficulty is:

Do you express the resulting file size or the amount saved? “30%” could mean you “30% of the original file size” or “you shaved off 30% of the original file size”. You could denote the difference with a sign, like “-30%” but that still confuses people. We ran both options by a lot of our colleagues.

“x% of the original file size” is the least ambiguous, but who has the space to put that entire phrase in their app :-/

Yes, that is Jake. This is Surma.

You seem to be right. Gonna fix the CLI (the CLI is my doing)

It _is_ cached, but the wasm binary itself as well as the optimized version to improve startup times. The cache however is per origin. So no other origin can make use of the cache which prevents the fingerprinting aspect.

I did test that and maybe should have mentioned it in the article :) The repo history actually still has an RGBA buffer dump I think.

Idk man. webassembly.org — the site authored by the inventors — literally starts with “WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.”

That’s the whole point. V8 is _really_ good at taking any form of JS code and making it fast, without me having to apply optimizations. The other languages only started being competitive once I hand-optimized them.

Author here.

Using ASC was intentional, _because_ it is somewhat immature, and still manages to outperform JavaScript in the first two cases.

In the third case, where I couldn’t get ASC to outperform JavaScript, I tried Rust and C++ as well.

Author here.

It’s a trade-off for simplicity. It’s a small team and they are still working towards feature completeness. Deferring optimization to Binaryen is the easy way out at the cost of not having high-level optimizations. If they finish their IR, that will most likely change.

Author here!

You even included in the quote: It’s important to warm-up the code is so you don’t measure a mixture of performance characteristics between interpreted JS and compiled jS. How long the warmup takes is _incredibly_ device dependent, so instead I measured Ignition and SparkPlug independently so you get a feel for the speedup. I did not discard that at all in the comparison.

To be safe: There is some more graphic violence, but due to the dithering it’s not very offensive imo. However, pretty much the entire crew does die rather brutal deaths (and that’s what the plot of the game is centered around).

TIL! I just redeployed with these styles added. Should be live in a couple minutes. Thank you.

Ah, this happens when Firefox/Chrome scales the image. I added a note to the article a couple hours ago, not sure if you saw that.

If you open the image in question in a new tab (to prevent any scaling) you’ll see the image as intended with the “desired” effect.

This is a lovely compliment. Thank you for taking the time to write it :)

Author here! I don’t think many people have researched or optimized on this, but I also work on https://squoosh.app, and from that experience I know that dithering makes compression _worse_ most of the time (unless you use PNG and use a super small palette of colors). Interesting idea tho!

Well, I hadn’t heard of it, so I’ll read this tomorrow :D Thanks for sharing.

Thanks for the kind words!

I saw this book mentioned a couple of times during my research. I guess I should read it.

... I think I need to buy an Inkplate now

Omg I didn’t think of this application for dithering. Love that.

Author here!

I can only refer to an article another comment also already mentioned. It is _excellent_ and covers animation & dithering: https://bisqwit.iki.fi/story/howto/dither/jy/

To be clear: It doesn’t _require_ JS at all. The page _is_ static and works with JS disabled. It uses JS for YouTube, Login and the interactive widgets at the bottom.

As you already hinted, SABs have been widely disabled. Chrome is currently the only browser who has SABs and therefore the only browser with support WebAssembly threads.

Workers, on the other hand, are available everywhere. And serialization seems to be far less costly than most people think. In the apps that I have written that make use of a off-main-thread architecture, structured clone has not been my bottle-neck.