Live data from Hacker News

Inside a fast CSS engine

hacks.mozilla.org

91–100 of 144 posts

Re: Inside a fast CSS engine

#91
post #79

I wish this post included some benchmarks or measurement.

Just asked Emilio on IRC for some quick numbers. emilio: pcwalton: wrt gecko we have stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25 and similar emilio: pcwalton: there's also the tp6 numbers, though those also measure CSS parsing and other stuff that isn't the style engine per se pcwalton: emilio: our tp6 numbers are improved over Gecko at this point, yes? :) emilio: pcwalton: amazon by a huge am…

Thanks for the pointer! Sadly, I couldn't find any concrete numbers or tests to run at that link.

I'm mildly interested in impl details. But I'm more interested in what it speeds up and how it was measured (ideally in a form where I could try my own old-to-new and cross-browser comparisons, but just numbers would be interesting too).

Re: Inside a fast CSS engine

#92

Earlier quoted context omitted.

You don't even need the whole web platform to build these sort of UIs -- in theory, you could use the WebRender engine to render CSS-box-like UIs. You could avoid some of the weaknesses of the web platform like the memory-heavy DOM. I think this would be an excellent target for a React Native-like framework for desktop, as it would support the full generality of CSS with excellent performance.

Qt has been doing something this for a long while: https://doc.qt.io/qt-5/stylesheet-syntax.html

QML is more comparable to what the grandparent means. Stylesheet support still works on the fairly rigid structure of nested widgets.

Re: Inside a fast CSS engine

#93

I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have? Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs…

No, I created Code Cartoons in my spare time. After I worked at Mozilla for a while, I pitched the idea of me making Code Cartoons explaining the things we were developing in Emerging Technologies. My (current) boss was super into the idea.

I talked more about this on a recently recorded Hanselminutes podcast. It should come out soon.

Re: Inside a fast CSS engine

#94
post #91

Earlier quoted context omitted.

Just asked Emilio on IRC for some quick numbers. emilio: pcwalton: wrt gecko we have stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25 and similar emilio: pcwalton: there's also the tp6 numbers, though those also measure CSS parsing and other stuff that isn't the style engine per se pcwalton: emilio: our tp6 numbers are improved over Gecko at this point, yes? :) emilio: pcwalton: amazon by a huge am…

Thanks for the pointer! Sadly, I couldn't find any concrete numbers or tests to run at that link. I'm mildly interested in impl details. But I'm more interested in what it speeds up and how it was measured (ideally in a form where I could try my own old-to-new and cross-browser comparisons, but just numbers would be interesting too).

The STR for that bug are in comment 3, but I can try to get something better when I'm back home (on my phone now).

We get significant speed ups from parallelism and such on big doms over all during page load, but we also get speedups from dynamic change handling implementing smarter invalidation than Gecko, which basically restyles the whole subtree / every sibling if it finds a relevant combinator affected by a change.

WebKit does much better than Gecko for class and other attribute changes, at least for descendants, where you go down with the relevant selectors. Stylo's system is relatively similar, but doing selector matching ltr, and handling the same way state and id changes.

You can see components/style/invalidation/element in the servo repo for the relevant code in that regard.

Re: Inside a fast CSS engine

#95
post #19

Parallel processing demonstrates benefits only if you have physical cores to run code on them. If just one core is available for the app then parallel processing is a loss due to thread preemption overload. Is there any real life examples of achieved speedup?

> Is there any real life examples of achieved speedup? Yes, most pages have significant speedups during the initial restyle especially. Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example. Of course, styling is only one part of the whole, so your overall speedups are limited by the rest of the rendering pipeline. That's Amdahl's Law for you. But th…

> Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example.

Do you have absolute numbers? If it's 100 vs. 300 ms, that'd be huge. If it's 1 vs. 3 ms, I don't really care.

Re: Inside a fast CSS engine

#96

I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have? Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs…

No, I created Code Cartoons in my spare time. After I worked at Mozilla for a while, I pitched the idea of me making Code Cartoons explaining the things we were developing in Emerging Technologies. My (current) boss was super into the idea. I talked more about this on a recently recorded Hanselminutes podcast. It should come out soon.

Nice!

Did you also do the React Fiber cartoons?

Re: Inside a fast CSS engine

#97
post #96

Earlier quoted context omitted.

No, I created Code Cartoons in my spare time. After I worked at Mozilla for a while, I pitched the idea of me making Code Cartoons explaining the things we were developing in Emerging Technologies. My (current) boss was super into the idea. I talked more about this on a recently recorded Hanselminutes podcast. It should come out soon.

Nice! Did you also do the React Fiber cartoons?

Yes, that was me :) I've created a lot of cartoons around things in the React ecosystem. I've also done cartoons on WebAssembly and SharedArrayBuffer/Atomics.

Re: Inside a fast CSS engine

#98

Earlier quoted context omitted.

It's a possible eventual goal but we don't have concrete plans or a timeline. Stylo and the like let us get improvements out to users well before we need to deal with that.

Also, all the discussion so far seems to focus on desktop firefox, are these improvements coming to firefox for android, or is that a longer term project, perhaps when servo is ready?

There's more to putting it in the product than just the code, but the style system in Servo does already work on Android. Once 57 ships, I suspect there will be some resources to start doing the remaining product integration work for Firefox on Android.

Re: Inside a fast CSS engine

#99
post #96

Earlier quoted context omitted.

Nice! Did you also do the React Fiber cartoons?

Yes, that was me :) I've created a lot of cartoons around things in the React ecosystem. I've also done cartoons on WebAssembly and SharedArrayBuffer/Atomics.

Cool. I had the feeling they looked similar, but I didn't think someone who does this whole low-level stuff AND works for Mozilla would also like React, which got much hate from non-FB employees lately :D

Re: Inside a fast CSS engine

#100
post #96

Earlier quoted context omitted.

Nice! Did you also do the React Fiber cartoons?

Yes, that was me :) I've created a lot of cartoons around things in the React ecosystem. I've also done cartoons on WebAssembly and SharedArrayBuffer/Atomics.

The one on WebAssembly was also very informative, thanks!
Post reply on HN