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…
Inside a fast CSS engine
131–140 of 144 posts
Re: Inside a fast CSS engine
#132Earlier 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.
Re: Inside a fast CSS engine
#133Earlier 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…
Re: Inside a fast CSS engine
#134Earlier 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.
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
#135I 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
#136Earlier 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?
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
#137Earlier 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.…
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
#138Earlier 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…
Re: Inside a fast CSS engine
#139Re: Inside a fast CSS engine
#140I 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…