4 ms·

"But nowadays we browse the web on ... that have much more sophisticated processors, often with two, four or even more cores." Having batched GPU rendering / r

by c-smile 10y ago

"But nowadays we browse the web on ... that have much more sophisticated processors, often with two, four or even more cores." Having batched GPU rendering / rasterization makes real sense, yes. When it shown, the browser is the largest screen space consumer. 4K displays (300ppi) increased number of pixels that need to be painted by 9 times. Thus CPU rendering / rasterization is not the option anymore, yes. But browser is not the only process competing for those cores. 2 or even 4 cores ... You have more front running applications than that these days. Some of them are invisible but still CPU intense. In order to get significant benefits from parallelism in browsers the number of cores shall be measured in tens at least I think. If not even more than that. To run things in parallel like bunch of Cassowary solvers for each BFC container. I suspect that the main bottleneck at the moment is in existence of methods [1] that force synchronous layout / reflow of the content. These are things that kill parallel execution. DOM API shall change towards batch updates or other more parallel friendly means. [1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a

pcwalton 10y ago
> 2 or even 4 cores ... You have more front running applications than that these days. Some of them are invisible but still CPU intense. Occasionally that's true, but users typically interact with just one app at a time. Even if background tasks are running and taking up CPU time (which is not the common case—if it were then games wouldn't work!) the foreground app should get priority in using the CPUs. So background apps aren't relevant here, any more than background apps are relevant in a single-core scenario. > In order to get significant benefits from parallelism in browsers the number of cores shall be measured in tens at least I think. If not even more that that. To run things in parallel like bunch of Cassowary solvers for each BFC container. First of all, that's not true, based on our measurements. We've seen large improvements with as few as two cores. Second, CSS parallelizes just as well if not better than Cassowary: unless text actually has to wrap around floats we can lay out every block in parallel. Even when there's a lot of text wrapping around floats, we can lay out all the floats in parallel. > These are things that kill parallel execution. Even if we had batch updating APIs, existing browser engines would be in no position to offload layout and restyling to a separate thread. The DOM and render tree are too intertwined in typical engines.
- c-smile 10y ago
  "we can lay out every block in parallel" I wouldn't be so optimistic, especially with flexboxes and grids. display:grid; grid-columns: 1fr max-content 1fr minmax(min-content, 1fr); The above requires intrinsic min/max width calculations (full layouts de facto) before you can even start doing layout of cells in parallel. The same is about our old good friend <table> by the way where each cell is BFC.
  - pcwalton 10y ago
    Intrinsic inline-sizes have been handled just fine in Servo from day one with a parallel bottom-up traversal. This is well-known; the technique goes back to the Meyerovich paper.

by c-smile 10y ago

pcwalton 10y ago

> 2 or even 4 cores ... You have more front running applications than that these days. Some of them are invisible but still CPU intense. Occasionally that's true, but users typically interact with just one app at a time. Even if background tasks are running and taking up CPU time (which is not the common case—if it were then games wouldn't work!) the foreground app should get priority in using the CPUs. So background apps aren't relevant here, any more than background apps are relevant in a single-core scenario. > In order to get significant benefits from parallelism in browsers the number of cores shall be measured in tens at least I think. If not even more that that. To run things in parallel like bunch of Cassowary solvers for each BFC container. First of all, that's not true, based on our measurements. We've seen large improvements with as few as two cores. Second, CSS parallelizes just as well if not better than Cassowary: unless text actually has to wrap around floats we can lay out every block in parallel. Even when there's a lot of text wrapping around floats, we can lay out all the floats in parallel. > These are things that kill parallel execution. Even if we had batch updating APIs, existing browser engines would be in no position to offload layout and restyling to a separate thread. The DOM and render tree are too intertwined in typical engines.

c-smile 10y ago
"we can lay out every block in parallel" I wouldn't be so optimistic, especially with flexboxes and grids. display:grid; grid-columns: 1fr max-content 1fr minmax(min-content, 1fr); The above requires intrinsic min/max width calculations (full layouts de facto) before you can even start doing layout of cells in parallel. The same is about our old good friend <table> by the way where each cell is BFC.
- pcwalton 10y ago
  Intrinsic inline-sizes have been handled just fine in Servo from day one with a parallel bottom-up traversal. This is well-known; the technique goes back to the Meyerovich paper.