bilkow

- You can't download the game without internet, including re-downloading because you had to free up space

- You can't download the game after they have retired their servers (or if their servers are down / having issues)

- The game ends up taking a lot more storage space as updates are usually tiny when compared to the base game. For reference, the Switch 1 version of Zelda Tears Of the Kingdom takes 16 GB while the latest update takes only 500 MB.

Thanks for the detailed explanation and example!

> Well, the default in avifenc can always be changed.

Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default. I also usually prefer to use the default unless I have a good reason not to do so.

And I think that `--layered` is fine as a name, and I had realized that as the docs were right below the docs for `--progressive`, which do mention it encodes a "layered image", although it could use an example on how to use it effectively.

> I'm surprised HN likes progressive loading to be more granular, and use that to push back.

Not necessarily? Using more passes would probably help in specific the metric in the comment I was responding to, by making AVIF possibly look better on a larger fraction of the decoding time. I mostly interpreted your comment as saying that it would have been better if they used more passes, and that's on me.

The reason I was comparing the breakpoints in the decode time was because I was responding to an allegation that "even there, AVIF looks better for 90% of the decode time", and I decided to point out that's not not the case and chose some pretty clear breakpoints that are very hard to argue about. Very subjectively the actual breakpoints could be a lot earlier, for the Poke the AVIF only looks better (in the sense that you can figure out what's there better) in a 6% range (from 2 to 8%) or maybe 9% (from 2% to 11%) of the decode time. There are many (relatively big) seeds that are just not there on the AVIF side, but you can distinguish on the JXL side, even if they're blurry. Percentages used in reference to the JXL side.

> I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.

Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.

> Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.

Sure, I see what you mean, you can distinguish more image element in the AVIF example, that's true. I don't like the lack of consistency and some of the artifacts to the point where I'd prefer not using progressive encoding, so that's not what I'd call "usable", but that seems like a matter of taste. It surely does look closer to a "final image" than the JXL at that point.

As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB. You can get a rough idea of what's the image about and the elements on it, with roughly the right colors, but it's still clearly loading, so there's no confusion, and without many "artifacts" like the progressive AVIF in the example (no idea if AVIF is able to make progressive encoding in a way that's more "blurry"). The caveat is that more steps are better when it takes too long (more than a few seconds) so the user knows it's not stuck.

> their demo only uses two passes for progressive AVIF -- it's just their choice

Also worth mentioning: AFAIK "their choice" here is just the default, i.e. what `avifenc --progressive` outputs, so maybe if the default is suboptimal, it could be improved?

> Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!

Usable for what? As a clearly loading image / placeholder, I personally like the JXL version better (as already indicated in my previous comment). As a final image I think both of them are unusable, and if that's the intention I think it would be better to encode both aiming for very low quality, maybe also reducing the resolution, without progressive loading, then compare. My understanding is that AVIF is usually better at very low bitrates, so it would probably be better, but I don't think this example "proves" that.

> For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time.

I'm not sure I agree? IMO after about 30% most images look better on JXL than on AVIF, the exceptions being the pigeon, which looks better on JXL after 43% (still less than half) and the sunflower, which looks better on 66% (but you can clearly see what's on the image a lot earlier). Also, blurry convey better the idea of loading and the AVIF version may have some weird artifacts / look weirder (although that's subjective), for example the Quechua woman's eyes are very distorted on the progressive AVIF and, on the Poke bowl, some of the seeds on top of one of the top radish pieces are kind of missing / look like a shadow (while other seeds of the same size appear). In contrast the JXL version is usually blurrier and less saturated at the beginning but is more "uniform/reliable" (distorts all of the "objects" more or less the same), and later it looks finished but actually isn't (which may be a problem on its own).

Let's pretend it's OK for them to just drop your domain, ignoring the stability and security issues that arise from that (and how ICANN should prevent that, in theory).

How about the fact that you paid for a service for 10 years and they decided to stop providing it midway? Will you at least get a refund? If not, that's surely illegal right?

Loved it! I made this version for `fish` and `wl-clipboard`:

    function clipboard-format-json
        # Inspired by https://chris48s.github.io/blogmarks/posts/2021/jsontidy/
        if set -l formatted "$(wl-paste | jq '.')"
            wl-copy $formatted
        end
    end

By saving it to .config/fish/functions/clipboard-format-json.fish, it should immediately work

I also discovered the joy of shift-selecting a big range of tabs and pressing ^W only once. It also feels pretty good, but in a slightly different way...

> never displays or updates apps correctly. Half the time an app showed up on the website that didn't show up on the phone app. The other half of the time even when I did get something installed, it would just never understand that an update existed and needed to download and update a given app

You probably "just" need to pull down while on the "Latest" or "Updates" tab, to update your repository (it will show a small banner at the top while it's doing that). It's incremental, so it may take a while if it has been some time since you last did it (and auto-updates are disabled).

The way F-Droid works is that it downloads the whole index and then the catalog, version checks, etc, all runs locally, quite similarly to some package repositories actually.

I am not claiming its intuitive, but I think that part works fine once you understand how it works.