Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside a fast CSS engine

hacks.mozilla.org

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Inside a fast CSS engine

#71

Post by matthewmacleod »

taeric wrote: post #35
matthewmacleod wrote: post #29

Earlier quoted context omitted.

If that’s what you want to do, the you should ‘nice’ your web browser (or use whatever priority mechanism your environment had available). Artificially limiting performance is absolutely the wrong approach!

It isn't artificially limiting. If my browser didn't need all of my cores to perform, we wouldn't be having this discussion. :) And I seriously question whether my browser needs this to perform well. I am not completely closed to the idea, but I am highly skeptical.

The fact that it's been done is some evidence that it's required. If it weren't, it's hard to imagine why limited resources would be wasted on it!

Almost every modern device running a browser has multiple cores, and that trend is almost certainly going to increase – so it definitely feels like allowing a core part of the web platform to expand across cores will be beneficial.

Re: Inside a fast CSS engine

#72

Post by JoshTriplett »

jamii wrote: post #69
JoshTriplett wrote: post #37

Earlier quoted context omitted.

Absolutely agreed; I'd love to see Servo used as a browser engine for apps. And if you fit within what Servo supports today, you can already do this. I've seen people demonstrate Android applications (written in Rust) that embed Servo.

> I've seen people demonstrate Android applications (written in Rust) that embed Servo. Do you have a link? I went looking for information about embedding Servo and found nothing.

https://blog.mozvr.com/webvr-daydream-support-lands-in-servo... for one, though that doesn't do a very good job of using Servo as a separate module.

I can't seem to find the original example I'm thinking of that showed how to build an Android application (using cargo-apk) that embedded Servo.

Re: Inside a fast CSS engine

#73

Post by masklinn »

robin_reala wrote: post #65
kristofferR wrote: post #58

It's such a shame Firefox (including the nightlies) kills my Mac (making most other applications hang/break), since the new versions are otherwise way better than Chrome. Does anyone know what it is about Firefox that makes the rest of my system unable to spawn new processes?

That’s weird. If you’re not attached to your profile you could try resetting it (go to about:support) and see if that fixes it. Otherwise I’d file a bug.

Seconded, I'm regularly opening FDE these days and never noticed anything odd on my mac.

Re: Inside a fast CSS engine

#74

Post by taeric »

matthewmacleod wrote: post #71
taeric wrote: post #35

Earlier quoted context omitted.

It isn't artificially limiting. If my browser didn't need all of my cores to perform, we wouldn't be having this discussion. :) And I seriously question whether my browser needs this to perform well. I am not completely closed to the idea, but I am highly skeptical.

The fact that it's been done is some evidence that it's required. If it weren't, it's hard to imagine why limited resources would be wasted on it! Almost every modern device running a browser has multiple cores, and that trend is almost certainly going to increase – so it definitely feels like allowing a core part of the web platform to expand across cores will be beneficial.

I challenge that. That it was done is as much evidence that it was doable as that it was required.

It is also a bloat race. Web pages are getting increasingly complicated. With very little benefit to end users. I'd wager a growing number of the cycles and network requests are going to tracking, nowdays. Not to mention the ui language doing more and more contortions to give us a page that could be much more succinctly described.

None of this is to say I want it stopped. I just have a feeling of concern that this is leading to an ever increasing march to faster and faster machines to do basic work.

Re: Inside a fast CSS engine

#75

Post by taeric »

sanxiyn wrote: post #68
taeric wrote: post #61

Earlier quoted context omitted.

I'm curious how well this plays with some of the fancier selectors. Adjacent sibling, in particular. I'm also curious if this pretty much prohibits ever having a parent selector. I guess you could do a first pass through the styles to remove any DAG nature from them?

DOM element has parent and sibling pointer, so there is nothing particularly difficult about adjacent sibling, later sibling, or even parent selector as far as selector matching goes. Avoiding restyling becomes more tricky, but nothing serious. "Parent before child" is for CSS inheritance, not for selector matching. For not-very-difficult details, read https://github.com/servo/servo/blob/master/components/select... s…

As soon as there are parent selectors, the pointers don't help. Specifically, if I restyle a parent, all children of parent need to be adjusted, right?

Siblings... I'm assuming there is nothing hard there. Positions, maybe?

Re: Inside a fast CSS engine

#76

Post by pcwalton »

taeric wrote: post #25
c-smile wrote: 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?

I have similar concerns. I'm all for using my machine to its fullest, but in large, applications like web browsing should be an additional thing I am doing on my computer, not something that thinks it can take the full computer. Though, I have to admit I am also a little torn on this. Yes, browsing is typically done "during compile" or some other task. However, I have also begun doing most of that work remotely so th…

This problem is the responsibility of the OS scheduler. One of the most important goals of any scheduler should be to give foreground UI processes that spend a lot of time sleeping in event loops priority. So if your OS scheduler is properly designed (as the ones in all major OS's are) a threaded browser shouldn't interfere with the system's responsiveness.

Re: Inside a fast CSS engine

#77

Post by vvanders »

oshepherd wrote: post #66
vvanders wrote: post #26

Earlier quoted context omitted.

You may want to be careful with that approach. Not all GPUs have the Z-Buffer fillrate to make that approach viable(esp on mobile). I've seen more than a few cases where it was actually faster to turn off Z-Buffering and do the overdraw. More than a few architectures share Z-Buffer bandwidth with other pipelines. On tiled architectures it'll also increase your tile count which can impact your per-drawcall overhead. F…

> Not all GPUs have the Z-Buffer fillrate to make that approach viable(esp on mobile). I've seen more than a few cases where it was actually faster to turn off Z-Buffering and do the overdraw. More than a few architectures share Z-Buffer bandwidth with other pipelines. Uh, mobile GPUs tend to be way, way ahead of desktop GPUs in Z-Buffer bandwidth (especially in relative terms) and you can't increase your tile count;…

Not quite, tile based GPUs tend to be better on Z-Buffer bandwidth but not all mobile GPUs are true tile-based GPUs.

The number of tiles can definitely change, it's something Qualcomm calls out directly in one of their talks[1]. As your tile count increases so does your setup cost for your drawcalls.

[1] https://youtu.be/SeySx0TkluE?t=41

Re: Inside a fast CSS engine

#78

Post by sanxiyn »

taeric wrote: post #75
sanxiyn wrote: post #68

Earlier quoted context omitted.

DOM element has parent and sibling pointer, so there is nothing particularly difficult about adjacent sibling, later sibling, or even parent selector as far as selector matching goes. Avoiding restyling becomes more tricky, but nothing serious. "Parent before child" is for CSS inheritance, not for selector matching. For not-very-difficult details, read https://github.com/servo/servo/blob/master/components/select... s…

As soon as there are parent selectors, the pointers don't help. Specifically, if I restyle a parent, all children of parent need to be adjusted, right? Siblings... I'm assuming there is nothing hard there. Positions, maybe?

I still don't see what problem parent selectors cause. Restyling parent happens anyway without parent selectors (say, by JavaScript), so it is handled. In https://github.com/servo/servo/blob/master/components/style/..., MustCascadeChildren is returned when you... must.

Re: Inside a fast CSS engine

#80

Post by pcwalton »

om2 wrote: 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 amount, facebook not yet I believe, but patches are on the queue that should make it turn around :)

emilio: pcwalton: happy to talk with mjs about impl details too, if he wants. I know a bit of WK stuff too :)

Post reply on HN