Alexander Kalenik

Nice thing about using Rust in @ladybirdbrowser: it becomes significantly easier to parallelize things when you have confidence that they're not racy! Here's what it looks like when we distribute JS parsing to a thread pool instead of parsing synchronously on the main thread:

@PavitraGolchha @awesomekling @ladybirdbrowser response stream, which means we can process chunks as they are arrive instead of waiting for the whole response body like it was before.

@awesomekling @ladybirdbrowser @KalenikW Just want to be clear - Are *requests* unbuffered or the response stream?

We switched all our network requests in @ladybirdbrowser to be unbuffered, which means we can now see ChatGPT responses incrementally as they come in! Props to @KalenikW for fixing this (and all the bugs it uncovered)!

google maps progress update: - implemented enough webgl support for globe view and vector tiles - libjs is much faster than a year ago, but there's still lots of optimization work to do before we can seamlessly decode tiles

using @ladybirdbrowser to read @ladybirdbrowser 😎

seeing platform differences from this angle makes it clear why i usually have a better software experience on mac. it's simply easier to build for.

more complicated apis compared to mac counterparts, and, more importantly, it's harder to make sure everything works consistently on different hardware, especially when you are a small team.

working on graphics in ladybird, it was surprising how hard it is to deliver something consistent on linux vs mac. currently our linux build lags behind both feature & performance wise, e.g. webgl is only supported on mac at the moment and

I've added basic pointer events dispatch and fixed a few issues with CSSStyleDeclaration. Now, it's possible to paint shapes on excalidraw.com. Implementing missing features for open-source web apps is so much easier than dealing with minified production websites.

It's possible to be productive programmer when you can't type fast It's possible to be productive programmer if you don't use IDE It's IMPOSSIBLE to be productive programer if you don't have extensive test suite to catch regressions

I checked a website saved couple months ago as a "nice image decoding stress test". Apparently, the combination of switching to libwebp for animated WebP decoding and using Skia for rasterization helped a lot there.

@mrunix0 yes, we use skia for webpage and canvas rasterization, although we still have a lot of work to do to efficiently coordinate painting from the LibWeb side

@KalenikW Hasn't Ladybird switched to SKIA as a graphics engine?

I tried to open Google Maps in Ladybird and was surprised by how not bad at all we are doing there even without WebGL or GPU-accelerated canvas!

after doing more research, it turned out o1's speculations were right. it just didn't know this thing named "The percentage height calculation quirk" and there is a spec for it #the-percentage-height-calculation-quirk" target="_blank" rel="nofollow noopener">quirks.spec.whatwg.org/#the-percentag…

frustrated trying to understand how engines resolve CSS percentages I reached out to o1. really impressed! not sure about the speculative part about how engines work, but the info based on the spec seems solid and even links to the relevant section! chatgpt.com/share/66f6c2f9…

Ladybird is almost capable of handling my daily github workflow. recently I fixed a performance issue where we were incorrectly invalidating layout on every scroll change in "File changes" page. it's still sluggish but good enough to review a small PR.

I'm not sure if it was intentional or a design mistake with "overflow", but newer CSS properties like "transform" and "clip-path" force an element to establish a stacking context, making implementation much simpler.

currently, that's not true, meaning each element within a stacking context could potentially have a different containing block and, therefore, a different clip rectangle and scroll offset.

If I could make just one change to the CSS standard, it would be ensuring elements with "overflow: hidden" and "overflow: scroll" automatically establish a stacking context.

this is totally fine until you try to speed things up with optimizations like scrollable layer compositing. then, it becomes frustrating when one layer can be split into three simply because it's interleaved with an absolutely positioned element.