On Aug 28, 2014, at 5:45 PM, Clark Gaebel wrote:
> Running this on Firefox takes 500 ns/iteration. Chrome takes 700 ns/iteration.
>
> Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
> much) for a parallel architecture, when simple queries experience a 10x
> slowdow
I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work
doubles as a nice way to fix it :)
Patrick
On August 28, 2014 7:18:27 PM PDT, Robert O'Callahan
wrote:
>On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton
>wrote:
>
>> It might happen if layout is flushed from outside t
Good point. I believe that the answer is no in general, but there are special
cases in which the flow tree must be rebuilt at least in part. Normally the
flow tree can be reused on window resize/device rotation/CSS animation, but
there are special cases in which it can't (e.g. media queries). Bu
On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton wrote:
> It might happen if layout is flushed from outside the script task; window
> resizing/device rotation being what immediately comes to mind, as today in
> Servo those events go straight from compositor to layout without hitting
> the script t
Do such events always cause the layout task to require DOM access to create the
flow tree? If so, the layout task would still have to wait for the script task
to finish, meaning that layout still can’t occur unless forced by script.
Cameron
On Aug 28, 2014, at 7:10 PM, Patrick Walton wrote:
>
It might happen if layout is flushed from outside the script task; window
resizing/device rotation being what immediately comes to mind, as today in
Servo those events go straight from compositor to layout without hitting the
script task at all. (As an alternative design, we could route such eve
On Fri, Aug 29, 2014 at 12:56 PM, Cameron Zwarich
wrote:
> Is it strictly enforced that the script task never sees inconsistent views
> of layout? This came up in the other thread about threading, but what
> prevents this incorrect scenario?
>
> 1) The script task takes the mutex to access one pr
On 8/28/14 6:06 PM, Cameron Zwarich wrote:
I assumed that was the case, but was going to wait for his response before the
obvious follow-up question. We did a similar thing with iOS WebKit: a recursive
mutex that was only released on the turn of an event loop. It was universally
regarded as be
On Aug 28, 2014, at 6:00 PM, Patrick Walton wrote:
> On 8/28/14 5:56 PM, Cameron Zwarich wrote:
>> It’s nice that it’s so close to the competition. It would be interesting to
>> see numbers on ARM as well, since the relative cost of the atomic
>> instructions might be higher, even in the uncont
On 8/28/14 5:56 PM, Cameron Zwarich wrote:
It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task neve
It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task never sees inconsistent views of
layout? This ca
Hi servo-dev!
Servo exists to validate the idea that parallel browser architectures work.
Going parallel isn't always a good thing, and can sometimes be worse if there's
too much communication overhead. For example, in the current Servo design,
javascript is run in a different task than layout.
12 matches
Mail list logo
