Live data from Hacker News

Inside a fast CSS engine

hacks.mozilla.org

131–140 of 144 posts

Re: Inside a fast CSS engine

#131

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…

YES, this! Who on earth does that?

Re: Inside a fast CSS engine

#132

Earlier quoted context omitted.

> Just compare the download page of Libre Office ( https://www.libreoffice.org/download/download/ ) with that of Firefox. Without the budget of Mozilla, there is no time to put enough thought and effort on presentation. Our volunteers are our money. I wear like five different hats in LibreOffice and do not get paid for any of them. If I focus on web layouts for some weeks, I watch in horror as our unconfirmed bug sta…

As a fellow open source developer I completely understand you. Thank you for your work on LibreOffice. Having said that, the grandparent reflects an undeniable truth of our time. User expectations are high, users are "spoiled": they expect it all and they expect it for free. Not commenting on whether that is a good or bad thing, just pointing out that it is true.

Yes, psychologically it is healthier to draw motivation from the fun of working with other contributors. I also like delegating stuff to others and that is a really good habit for avoiding burnout.

Re: Inside a fast CSS engine

#133
post #126
post #102

Earlier quoted context omitted.

I was basically restating the restriction for the parallel scan. It goes from parent down so that during the scan you don't do something that causes the scan to have to restart. I was also shooting from the hip for things I'm interested in, here. I'm not sure it matters. But, if on scanning, you pick relevant rules to apply based on the path to a node, then I could see some trickiness on having to consider both the t…

Coming back to this before I finally sleep. I missed your point about selector matching and style application. I think that is ultimately where my hip shot missed on this. (I have never had to reserve the right to be wrong. Just to assume it. :) I still feel there is some danger there, but I think that is just clinging to an initial shot. I am curious why rust's help was needed to get this, now. A basic thread pool s…

Right, you don't need Rust to do this. In fact, Qualcomm did this with C++ and TBB in 2013, see http://dl.acm.org/citation.cfm?id=2442543. Rust does give you peace of mind that parallel styling won't be endless source of bugs, or worse, vulnerabilities.

Re: Inside a fast CSS engine

#134
post #116
post #112

Earlier quoted context omitted.

Metajack mention power usage with parallelization briefly here[0], but doesn't provide the data. [0] https://youtu.be/7q9vIMXSTzc?t=35m (2015)

To be clear, the reasoning is sound on this argument. I'm skeptical due to it never having delivered data, though. :( I want it to be true. I expect that someone should be able to show this with data. I've never seen it done, though.

You can collect much of this data for yourself on a GNU Linux system by using the cgroups feature of the Linux kernel which is more powerful than nice https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t... .

Using the various CPU* options, you can turn on CPUAccounting, pin a given process and its children/threads to a range of CPUs, place CPUQuotas and so forth. There's a lot of power and granularity there.

I know, anecdotally, that devops/sysadmin folk use this to also audit and test energy consumption of processes over time. (Certain popular PID 1 programs have a run tool that allows you to easily, dynamically change and audit process resource usage.)

My typical use case, for instance, is auditing and managing various Emacs' processes lifetimes while running potentially racy elisp code.

Re: Inside a fast CSS engine

#135

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.

Which tools do you use to make the drawings? Just a tablet?

Re: Inside a fast CSS engine

#136
post #128

Earlier quoted context omitted.

We're hoping to have stylo in 57, and I would expect it to be on android in the next release (58), but no promises. Basically we intend for it to work eventually on android, but it didn't get prioritized.

I can turn on `layout.css.servo.enabled`, on Firefox 55 Android (and Desktop). What does it mean? If I understand correctly, Firefox will have this property turned on by default in 57/58 but it's possible to have it early?

No, it won't do anything on 55. Or on 56/57 Android.

Stylo can be disabled at build time, and this was the case for 55 and is still the case for android. We don't remove the associated prefs in that case (about:config doesn't have UX because it's not exactly user facing).

You can go to about:support to see if stylo is actually enabled. There's a "stylo" column. It's not there in 55, but no 55 release has stylo enabled at build time; so if you don't have that column at all, stylo isn't there.

Re: Inside a fast CSS engine

#137
post #134
post #116

Earlier quoted context omitted.

To be clear, the reasoning is sound on this argument. I'm skeptical due to it never having delivered data, though. :( I want it to be true. I expect that someone should be able to show this with data. I've never seen it done, though.

You can collect much of this data for yourself on a GNU Linux system by using the cgroups feature of the Linux kernel which is more powerful than nice https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t... . Using the various CPU* options, you can turn on CPUAccounting, pin a given process and its children/threads to a range of CPUs, place CPUQuotas and so forth. There's a lot of power and granularity there.…

I know the data can be gathered. Could go even more direct and measure power usage of the computer before and after the upgrade.

It would be nice if everyone pushing some of these would collect some data for their claims, though. Especially if any of them have better setups (read: more than the single machine I have).

Re: Inside a fast CSS engine

#138
post #122

Earlier quoted context omitted.

That's honestly one of those big differences between Mozilla and the tons of other idealistic free/open source projects out there. They care about presentation. They care about clarity. They care about layout. They care about style. IMO understanding how to appeal to non-tech-y users (and that tech-y users don't always want to sift through 5 pages of links to SDK-tarballs when trying to download a software) was how t…

> Just compare the download page of Libre Office ( https://www.libreoffice.org/download/download/ ) with that of Firefox. Without the budget of Mozilla, there is no time to put enough thought and effort on presentation. Our volunteers are our money. I wear like five different hats in LibreOffice and do not get paid for any of them. If I focus on web layouts for some weeks, I watch in horror as our unconfirmed bug sta…

Thank you for all your work on Libre Office.

Re: Inside a fast CSS engine

#140

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…

Drawing is learned like any other skill. Just practice it for a while and you will become better at it
Post reply on HN