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

11–20 of 144 posts

Re: Inside a fast CSS engine

#11

Post by coldtea »

jancsika wrote: post #4

> 4. Paint the different boxes. Is this really what happens under the hood? 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? 2. If I overlap 52 s like a deck of cards, does the browser really paint all 52 s before compositing them? 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rec…

>. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them?

Well, if they have alpha, it should.

Re: Inside a fast CSS engine

#12

Post by Manishearth »

hamandcheese wrote: post #5
robin_reala wrote: post #2

I turned this on a couple of weeks ago on Nightly and have noticed precisely zero problems, and a really nice little speedup on CSS-heavy sites. Really good to see large chunks of parallelised Rust code start making their way over from Servo to Firefox.

Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

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.

Re: Inside a fast CSS engine

#13

Post by [deleted] »

hamandcheese wrote: post #5
robin_reala wrote: post #2

I turned this on a couple of weeks ago on Nightly and have noticed precisely zero problems, and a really nice little speedup on CSS-heavy sites. Really good to see large chunks of parallelised Rust code start making their way over from Servo to Firefox.

Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

[deleted]

Re: Inside a fast CSS engine

#14

Post by mbrubeck »

jancsika wrote: post #4

> 4. Paint the different boxes. Is this really what happens under the hood? 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? 2. If I overlap 52 s like a deck of cards, does the browser really paint all 52 s before compositing them? 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rec…

In a web browser, typically the layout engine generates a "display list" which is a list of drawing commands that includes all of the rectangles, borders, text, etc. It hands the display list to a graphics engine to be rasterized. The graphics code may optimize the display list before rasterizing it, doing things like removing items that are completely occluded.

Re: Inside a fast CSS engine

#15

Post by rbanffy »

lucideer wrote: post #6

It's great to see any company going into detail about their technical implementation, so I'm extremely hesitant to be critical, but I'm really curious who the target audience for this one particular article is. It's a very very odd mix of language that sounds like it's directed at a very young child and standard technical speak. Not the usual for the Hacks blog. Not to fault the article too much, but I just found the…

Open source depends on people wanting to work on it. Firefox is a very intimidating beast under the hood. Making it interesting is a vital important goal.

Re: Inside a fast CSS engine

#16

Post by yorwba »

jancsika wrote: post #4

> 4. Paint the different boxes. Is this really what happens under the hood? 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? 2. If I overlap 52 s like a deck of cards, does the browser really paint all 52 s before compositing them? 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rec…

There is probably some trickery going on to optimize e.g. completely hidden elements. But when you compare the two options of "loop through the rectangles from below and for each pixel in the rectangle set its color" and "for each pixel, determine the rectangle it is in and set its color accordingly" the amount of work is not much different. You could speed up the second strategy for nested rectangles by using a smart search structure, but this will most likely be trumped by specialized rendering hardware that can paint lots of rectangles very fast but isn't very good at branching logic.

Re: Inside a fast CSS engine

#17

Post by Brakenshire »

Manishearth wrote: post #12
hamandcheese wrote: post #5

Earlier quoted context omitted.

Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

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?

Re: Inside a fast CSS engine

#18

Post by pcwalton »

jancsika wrote: post #4

> 4. Paint the different boxes. Is this really what happens under the hood? 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them? 2. If I overlap 52 s like a deck of cards, does the browser really paint all 52 s before compositing them? 3. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rec…

> 1. If I overlap 52 html s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them?

Browsers don't typically do very good occlusion culling in general.

WebRender aims to change that, by using the hardware Z-buffer. :)

Re: Inside a fast CSS engine

#19

Post by c-smile »

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?

Re: Inside a fast CSS engine

#20

Post by nickpsecurity »

JoshTriplett wrote: post #8
hamandcheese wrote: post #5

Earlier quoted context omitted.

Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

Ideally it would be both; at a minimum, it should be a full browser engine, suitable for embedding (like WebKit, and unlike Gecko).

I second this for diversity and safety in rendering engines if nothing else. Plus, kiosk-style systems might find good use out of it if it was lean since they can match how they develop their web apps to what Servo supports. Finally, if small and using portable layer on bottom, it could be mixed with self-healing systems like QNX or Minix 3.
Post reply on HN