JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.

And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser.

I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.

> I am curious if the equation of CPU-determined graphics being faster than being done on the GPU has changed in the last decade

If you look at Blend2D (a CPU rasterizer), they seem to outperform every other rasterizer including GPU-based ones - according to their own benchmarks at least

Blaze outperforms Blend2D - by the same author as the article: https://gasiulis.name/parallel-rasterization-on-cpu/ - but to be fair, Blend2D is really fast.

You need to rerun the benchmarks if you want fresh numbers. The post was written when Blend2D didn't have JIT for AArch64, which penalized it a bit. Also on X86_64 the numbers are really good for Blend2D, which beats Blaze in some tests. So it's not black&white.

And please keep in mind that Blend2D is not really in development anymore - it has no funding so the project is basically done.

> And please keep in mind that Blend2D is not really in development anymore - it has no funding so the project is basically done.

That's such a shame. Thanks a lot for Blend2D! I wish companies were less greedy and would fund amazing projects like yours. Unfortunately, I do think that everyone is a bit obsessed with GPUs nowadays. For 2D rendering the CPU is great, especially if you want predictable results and avoid having to deal with the countless driver bugs that plague every GPU vendor.

That is fair - sorry for spreading mis-information! That's unfortunate to hear about Blend2D.

Blend2D doesn't benchmark against GPU renderers - the benchmarking page compares CPU renderers. I have seen comparisons in the past, but it's pretty difficult to do a good CPU vs GPU benchmarking.

Safari probably is that size because WebKit is a system framework, so it’s just the size of the UI code

The train now approaching platforms 1 and 2 is the…

The signals bounce off the tunnels a lot

> Why do you think the padding as a percentage is relative to the width of the parent? Do you think it was a happy accident? I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg.

It’s because you cannot do a percentage of a height unless your parent’s height is fixed - something that happens naturally maybe 1% of the time. You’d be missing vertical borders in almost every case with your suggestion

I hope with Alan Dye now out of Apple they will revisit a lot of what just happened. There’s been a lot of places where things have just become worse

I had a blog post on something similar (but less sophisticated)

https://jacobdoescode.com/2025/05/18/precomputing-transparen...

This is… essentially a BSP tree traversal without splitting polys that straddle a partition plane, right?

Since you’re on the topic, what ever happened to the multi threading stuff you were doing on JSC? Did it stop when you left Apple? Is the code still in JSC or did it get taken out?

I never really started on it other than writing up how to do it

Which multi-threading are you talking about?

iOS used to do this using the Cassowary constraint solver pre-SwiftUI. It’s the worst thing to work with. So much code turning on and off constraints, dynamically adding constraints when you have new views. And that’s before you get into conflicts