> Here it is.
>
> ~~There's two major things that are unfinished here:~~
> - ~~Dealing with the unroot_must_root lint. I'm not sure about the value of this lint with the new rooting API.~~ Done.
> - ~~Updating the Cargo.locks to point to the new SM and SM binding.~~ Done.
>
> I also included my fixes for the rust update, but these will disappear in a rebase. A rust update is necessary to support calling `Drop` on `Heap<T>` correctly when `Heap<T>` is inside a `Rc<T>`. Otherwise `&self` points to the wrong location.
>
> Incremental GC is disabled here. I'm not sure how to deal with the incremental barriers so that's left for later.
>
> Generational GC works. SM doesn't work without it.
>
> The biggest change here is to the rooting API. `Root` was made movable, and `Temporary` and `JSRef` was removed. Movable `Root`s means there's no need for `Temporary`, and `JSRef`s aren't needed generally since it can be assumed that being able to obtain a reference to a dom object means it's already rooted. References have their lifetime bound to the Roots that provided them. DOM objects that haven't passed through `reflect_dom_object` don't need to be rooted, and DOM objects that have passed through `reflect_dom_object` can't be obtained without being rooted through `native_from_reflector_jsmanaged` or `JS::<T>::root()`.
>
> Support for `Heap<T>` ended up messier than I expected. It's split into two commits, but only because it's a bit difficult to fold them together. Supporting `Heap<T>` properly requires that that `Heap::<T>::set()` be called on something that won't move. I removed the Copy and Clone trait from `Heap<T>` so `Cell` can't hold `Heap<T>` - only `UnsafeCell` can hold it.
>
> `CallbackObject` is a bit tricky - I moved all callbacks into `Rc<T>` in order to make sure that the pointer inside to a `*mut JSObject` doesn't move. This is necessary for supporting `Heap<T>`.
>
> `RootedCollectionSet` is very general purpose now. Anything with `JSTraceable` can be rooted by `RootedCollectionSet`/`RootedTraceable`. Right now, `RootedTraceable` is only used to hold down dom objects before they're fully attached to their reflector. I had to make a custom mechanism to dispatch the trace call - couldn't figure out how to get trait objects working for this case.
>
> This has been tested with the following zeal settings:
>
> GC after every allocation
> JS_GC_ZEAL=2,1
>
> GC after every 100 allocations (important for catching use-after-free bugs)
> JS_GC_ZEAL=2,100
>
> Verify pre barriers
> JS_GC_ZEAL=4,1
>
> Verify post barriers
> JS_GC_ZEAL=11,1
Source-Repo: https://github.com/servo/servo
Source-Revision: e7808c526c348fea5e3b48af70b7f1a066652097
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
See #6376
r? @Ms2ger
Snaps don't exist yet, putting up the @larsbergstrom signal. The snap need not exactly match this commit, anything in the vicinity, or just master, should work really. (yay stability)
There's no particular reason behind this rustup except that I want to keep Servo running on almost-master as much as possible.
Source-Repo: https://github.com/servo/servo
Source-Revision: 67b121c0b82f4a2107d7b015f60bd025e04dc336
Passing a function that measures TLS to WorkQueue is a bit weird, but I can't see how else to measure that data.
Source-Repo: https://github.com/servo/servo
Source-Revision: f03f584895f80deb08c77c817f6655609c4ee97c
This reduces the overhead of the work-stealing traversal function
significantly. It's especially important on ARM, where memory barriers are
expensive.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 836ac8a0b6daeecb865bcf35d2b39602398870ef
Prior to this change, a panic would occur if a CollectReport message was
received while the LayoutTask was shutting down. Now it just gets
ignored.
Source-Repo: https://github.com/servo/servo
Source-Revision: 74ef31cfc4805d6dbeaa9e4769f0ceb14d124733
The util component specified fnv and smallvec as dependencies and publicly
reexported both of them. Several other components utilized these reexports,
presumably because fnv and smallvec used to live in the tree so reexporting
made the transition easier.
These indirect dependencies through the util component are unnecessary.
This commit removes the fnv & smallvec crate reexports in the util component.
It exchange, it adds fnv & smallvec as dependencies to non-util components
wherever needed. Finally, it removes the fnv dependency from util as it is not
utilized anywhere in the util component.
Source-Repo: https://github.com/servo/servo
Source-Revision: 35000a9b854dc0989cc473aaec0ea8c082521c66
`LOCAL_CONTEXT_KEY` is currently a `Cell<*mut LocalLayoutContext>`. The use
of the raw pointer means that the `LocalLayoutContext` is not dropped when
the thread dies; this leaks FreeType instances and probably other
things. There are also some unsafe getter functions in `LayoutContext`
(`font_context`, `applicable_declarations_cache` and
`style_sharing_candidate_cache`) that @eddyb says involve undefined
behaviour.
This changeset changes `LOCAL_CONTEXT_KEY` to
`RefCell<Option<Rc<LocalLayoutContext>>>`. This fixes the leak and also
results in safe getters.
(Fixes #6282.)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0dec64caf01c98d10e72b73e35b994127c23e81f
* Add parser support for 3d transforms.
* Change ComputedMatrix to a representation that suits interpolation.
* Switch stacking contexts to use 4x4 matrices.
The transforms themselves are still converted to 2d and handled by azure for now, but this is a small standalone part that can be landed now to make it easier to review.
Source-Repo: https://github.com/servo/servo
Source-Revision: 05212b702dbafacd3d1d44e600139af8d7516308
This reverts commit 945adab / PR #6033.
The CSS Working Group resolved to drop this value from the spec:
http://log.csswg.org/irc.w3.org/css/2015-05-20/#e555680
The group was unable to come up with even a theoretical use case. Gecko only implemented this value for completeness. Other browsers vendors have clearly expressed they have no interest in implementing this.
Source-Repo: https://github.com/servo/servo
Source-Revision: 300c36f250f7838d8008d800644dc466bcd90a72
Part of #6224
I certainly didn't remove all of them; I avoided `unsafe` areas and also `components/script`
Source-Repo: https://github.com/servo/servo
Source-Revision: f6fe1953343a417b62fb310a380af7c6973849b0
This improves numerous pages, for example Wikipedia and Ars Technica.
Built on #5493.
Closes#177.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7561f7b83f27811683c1e724d75a935573a72813
I've done a bit of job to get this done. Right now readback is still used, but we have a `LayerId` -> `CanvasRenderer` map on the paint task, that we can use to get rid of that.
I'd want review, to see if this is a good approach (I know it's not the initial `CanvasId` -> renderer approach, but it's pretty similar, since a canvas involves a `PaintLayer`).
I had to do a bit of refactoring to avoid cyclic dependencies between canvas and gfx. I'd want you to review them too.
It's mergeable and doesn't break any tests :P
Some of my main concerns:
* Does the canvas render really need to be behind an `Arc<Mutex<T>>`?
* I can't clone a `NativeSurface` right now (that's why the `SendNativeSurface()` msg is unimplemented in the WebGL task). It should be easy to add that to rust-layers, supposing the caller is responsible to mark it as non-leaking, any reason to not do it?
cc @jdm @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: ad53e95080144485e74cd9b9d48ce75e20de4e36
This fixes a hang found while testing the jQuery test suite.
Source-Repo: https://github.com/servo/servo
Source-Revision: c51e9f04559f04f1e820b792261e1653c6869ee5
This improves Servo's performance on large pages.
Please double-check the logic when it comes to nested layers—I'm sure I've messed up some of the geometry calculations :)
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 0880e54f987bac7c34c934ef6ee36f46475b06e3
This fixes panics in RTL pages with floats (#6113) and partially fixes the positioning of RTL floats. There are some remaining issues with the layout of floats in RTL flows, which I'll file follow-up issues for.
Source-Repo: https://github.com/servo/servo
Source-Revision: 360c5d8235ae6fb5c51fba391be92c6cafe88425
Fixes#5856
This stops the panic, but the empty fragments tend to be non-empty if extended by `info.range_end_including_stripped_whitespace`, so I'm unsure if it's a requirement to include that instead of skipping for correctness? Perhaps there's a testcase needed for this behaviour?
Source-Repo: https://github.com/servo/servo
Source-Revision: 913c5677ab190ee6764c93c46899eb82ad067699
This property determines the background positioning area, that is the position of
the origin of an image specified using the 'background-image' CSS property.
'background-origin' is ignored when background-attachment is fixed.
Spec: http://dev.w3.org/csswg/css-backgrounds-3/#background-originFixes#6045.
r? @pcwalton
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 8c402728247c73268df9389948ee9a9d9e4063b2
`BaseFlow::position` is relative to the parent flow's margin box in the inline direction. We need to use the parent's `position` as the container size when translating it to physical coordinates, or we get incorrect results for non-LTR content.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 5a737bae1afd9dc48762a34fc041826e6d016e49
The basic idea is it's safe to output an image for reftest by testing:
- That the compositor doesn't have any animations active.
- That the compositor is not waiting on any outstanding paint messages to arrive.
- That the script tasks are "idle" and therefore won't cause reflow.
- This currently means page loaded, onload fired, reftest-wait not active, first reflow triggered.
- It could easily be expanded to handle pending timers etc.
- That the "epoch" that the layout tasks have last laid out after script went idle, is reflected by the compositor in all visible layers for that pipeline.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5e61ebaa05e5babb7b2fdd1347b6cdd23df38e62
