The old code was used by both layout and script, but was erroneously
borrowing for the layout case (which causes parallelism
problems). script now uses only `value_ref()` or `get_attribute()`, and
layout now has its own unsafe version that dances around the borrows of
`@mut Attr`.
The old code was used by both layout and script, but was erroneously
borrowing for the layout case (which causes parallelism
problems). script now uses only `value_ref()` or `get_attribute()`, and
layout now has its own unsafe version that dances around the borrows of
`@mut Attr`.
assign-heights phases.
This uses the new work-stealing deque. By default, 3/4 of a thread per
logical CPU is used. This can be tuned with the `-y` flag.
I measured a 65% reflow speedup on `perf-rainbow.html` and a 247% reflow
speedup on `http://en.wikipedia.org/wiki/South_China_Sea` on a 4-core
HyperThreaded Core i7. However, numbers were fairly volatile, especially
for the latter.
These two fixes are required for Android. We need to generate a toplevel crate map because it is used by both debugging and the libuv stuff. We also need to manually link against rustuv because we cannot dynamically inject it on Android.
r? @metajack
FIX#648
PR again #662, need to fix Makefile.in
I really want to use `$(Q)touch $@`. but, it is difficult to me.
So i will fix them next time. Can i ? I need to study Makefile.
Actually removing from the normal flow will come later.
There are some fixes for the positioned box offsets, like actually parsing percentages and naming consistency.
I hit this when trying to run servo in an ssh session. It hit an rtabort with
"fatal runtime error: thread-local pointer is null. bogus!" The exit is
required because at this point, the runtime is in a very weird state, and a
fail is going to explode even more violelently than the original unwrap did.
I hit this when trying to run servo in an ssh session. It hit an rtabort with
"fatal runtime error: thread-local pointer is null. bogus!" The exit is
required because at this point, the runtime is in a very weird state, and a
fail is going to explode even more violelently than the original unwrap did.
from the Compositor instead of a message with an immediate callback.
The problem was that the old model introduced a potential deadlock. If
the Constellation had a pending RenderReadyMsg in its queue when the
ExitMsg arrived from the Compositor, the Compositor would exit its
message loop and wait for the response from the Constellation. But,
the Constellation would send a SetIds message to the Compositor, which
also required a response - resulting in deadlock.
normally.
The old code made the mistake of attempting to shutdown the associated
pipelines itself, which caused race conditions with the constellation and
compositor, as they expect to be able to drain their message queues
before exiting.
Pointers to DOM nodes from layout could go stale if incremental reflow
does not correctly destroy dead nodes. Therefore, we ask the JavaScript
garbage collector to verify that each DOM node is indeed a valid pointer
before calling event handlers on it, and fail otherwise.
Depends on the `get-addressable-gc-thing` branches of `mozjs` and `rust-mozjs`.
r? @jdm
Pointers to DOM nodes from layout could go stale if incremental reflow
does not correctly destroy dead nodes. Therefore, we ask the JavaScript
garbage collector to verify that each DOM node is indeed a valid pointer
before calling event handlers on it, and fail otherwise.
