The_Decryptor
While there's an overhead to safer runtime environments, I wouldn't put much blame there. I feel like "back in the day" when something was inefficient you noticed it quicker because it had a much larger impact, windows would stop updating, the mouse would get laggy, music would start stuttering. These days you can take up 99% of the CPU time and the system will still chug along without any of those issues showing.
I remember early Twitter had a "famous" performance issue, where the sticky heading bar would slow systems down, because they were re-scanning the entire page DOM on every scroll operation to find and adjust the header, rather than just caching a reference to it. Meanwhile yesterday I read an article about the evolution of the preferences UI in Apple OSs, that showed them off by running each individual version of said OS in VMs embedded within the page. It wasn't snappy, but it didn't have the "entire system slows down and stops responding" issues you saw a decade or so ago.
Basically, devs aren't being punished (by tooling) for being inefficient, so they don't notice when they are, and newer devs never realise they need to.
It's got nothing to do with the specific search engine, it's Firefox thinking the URL itself is a search query and sending it as-is to the search engine.
I just tested it and it sent the URL to both DDG and to Google.
The dog?
Draw distance sucks for a vast ocean of plants and sealife. Seriously, I have a really good video card, and this fucking Unity engine can’t draw 500 feet in front of me.
If anything Subnautica lets you see too much.
PNG gets you the best compatibility and features, at the expense of file size. But I probably wouldn't use it for uploading photographs to the web of course.
WebP is the same, it's got a lossy mode (VP8) and a lossless mode (Which is more limited than PNG, but beats it where it overlaps). But to make it more complicated the lossless mode also has lossy processing modes, where it alters the image first to achieve smaller output sizes.
People have a long habit of turning JPEG files into PNG files, the file extension won't help you there. They also could have reduced the colour depth or resized it, all lossy operations. All it really tells you is that it can have an alpha channel.
As for AVIF, personally I don't like the format, it feels like an "open media" (But still patented) version of HEIF to oppose Apple. Like WebP it makes the (baseless IMO) assumption that a format designed to encode motion data is better at encoding still data than a format designed to encode still data. It's got all the limitations of a video format (It's got a max resolution, only supports 12bit images, and no progressive decoding), and they left out all the enhancements from WebP (The dedicated lossless mode, "lossless AVIF" files are huge and the last I checked badly supported, so nobody actually used them, and they just called very high quality settings "lossless")
A team inside of Google was working on WebP2 around the same time, that used AV1 but actually added the useful stuff like efficient lossless encoding, it got killed too in favour of AVIF.
So it depends on the specific HDR encoding used, Rec2020 is the most common ones you'll see (It's meant for "pure" setups, i.e. where the source and output are tightly linked, e.g. gaming consoles or blu-ray, or so) and the raw data won't look great. While something like HLG (Hybrid-Log Gamma) is designed for better fallback (As it's meant for TV broadcast, where the output device is "whatever TV the user has"), so should just look dimmer.
This is a HDR screenshot I took of Destiny 2, which uses Rec2020, tone mapped to SDR
And here's the raw screenshot data from before tonemapping.
If the second image had all the right HDR metadata, and the viewer supported it properly, then both images would match.
AVIF is generally smaller in size than both WebP and PNG. AVIF supports animation while PNG does not.
The lossless mode in AVIF is so bad that a BMP in a ZIP file produces smaller results.
Which makes sense, as it doesn't actually have a dedicated lossless mode (like WebP does), the encoder is just to not quantise the video data it produces.
JXL can do lossy images (like JPEG) and lossless ones (like PNG), and on average it'll produce smaller file sizes than both (While beating JPEG quality wise). The killer feature is that it can do lossless recompression of existing JPEG files and shave off about 20% of the file size, and it's reversible so you can turn those JXL files back into JPEG images for existing software.
The downside is that it was created by Google Research (among others), but the Chrome team made AVIF instead and decided that's what they'd support and nothing else.
At least Safari supports it.
Those chips not supporting RV23 isn't super surprising, they were released in 2023 while RV23 was only ratified in 2024.
Ubuntu requiring RV23 however does surprise me (I admit I didn't read the article), that seems premature, but I suppose it's a good baseline going forward. Last time I looked at any of the chips none of them supported the V extension, and those that did were majority only supported the incompatible pre-standard version.