This necessitated getting rid of the boxed trait object that was being
be passed between the script task and the image cache task.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e13ebf712de444132a6cc90f394c121d8d751c4c
To actually make the multiprocess communication work, we'll need to
reroute the task creation to the pipeline or the compositor. But this
works as a first step.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 1764267379a00b96a1df89f3917299a0c6fd325c
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: f778e0eecf7cd8a2b870d18c3c305ff10d6b1894
The idea here is to land this before making images and canvas IPC-safe,
because this will shake out bugs relating to the shared memory. There
are currently test timeouts that are preventing multiprocess images and
canvas from landing, and I believe those are due to the inefficiency of
sending large amounts of data in the unoptimized builds we test with. By
moving to shared memory, this should drastically reduce the number of
copies and `serde` serialization.
Under the hood, this uses Mach OOL messages on Mac and temporary
memory-mapped files on Linux.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: ed1b6a3513e7546b580693f554a081bc0c7c478a
This re-orders text according to the Unicode bidirectional layout algorithm, using the [unicode-bidi](https://github.com/mbrubeck/unicode-bidi) crate. It uses the natural order of the text based on Unicode character properties and the CSS `direction` property.
This does not yet support the CSS `unicode-bidi` property or the HTML `dir` attribute, but these should be straightforward to add.
r? @pcwalton. Also depends on servo/unicode-bidi#4.
Source-Repo: https://github.com/servo/servo
Source-Revision: d3a36fafd948d7b9366feeca44f9ca9ad012d706
Part of my long-term plan to stop exposing `unsafe_get()` outside the script crate.
Source-Repo: https://github.com/servo/servo
Source-Revision: 37a1e22515e98fbda93d7e856c5a67b21d9b00a4
- Use SmallVec<[T; N]>
- Make find_iframe a free function
- Make ProgressEvent use enums for bubbles and cancelable
- Change README, as `rust-snapshot-hash` is just a text file
Source-Repo: https://github.com/servo/servo
Source-Revision: aafc3dfa963b466303d5f241d69036f211aaad00
By doing this on either side of the call to the relevant tasks' start()
method, we don't need to store the mem::ProfilerChan or the reporter
name in the task itself.
Source-Repo: https://github.com/servo/servo
Source-Revision: cb52cc66581191b6f787a4a6d0d2844e2968b7eb
Also updates glutin with a crash fix that was exposed by this patch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ac80bff8e25be65e96daaf6b7403b11d23d561a
This checks every .toml file for an asterisk and prints an error if found.
Source-Repo: https://github.com/servo/servo
Source-Revision: 58e9bc6583b6ebbeb27e3b28a6b271ee48cd695a
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: ef9715203edf0a280d019b6e8823666f0e7020be
This will make it easier to adapt to IPC.
The trickiest part here was to make script tasks spawn new layout tasks
directly instead of having the pipeline do it for them. The latter
approach will not work in multiprocess mode, because layout and script
must run in the same address space and the pipeline cannot inject tasks
into another process.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: e06eaa0064f49bc215e3851f0a3686e1191b356a
This was the preferred pattern between the deprecation of Vec::from_elem and
the addition of the count argument to the vec![] macro.
Source-Repo: https://github.com/servo/servo
Source-Revision: 556c0e1509cb48b90f492bcf0f25d0ed14b015d1
This removes the possibility of a panic by checking a constraint at compile
time rather than at run time.
Source-Repo: https://github.com/servo/servo
Source-Revision: d7cf58d6f15c1b96884a5aef210a5c5d244abf54
Since I made unsafe code opt-in in layout, the unsafe code in this module has
been reduced to a single unsafe impl, so there is no reason to allow it in
the entire module.
Source-Repo: https://github.com/servo/servo
Source-Revision: ce81745a8ece10a81b3caaf80da41d7824c5105a
Fixes jumpiness on lots of Web sites.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: bbcd42773342a587a8515f34bdc3ca69a380c0a8
I wrote this patch that makes the test from #6542 render as expected but I am not confident it is actually the right fix. Should the padding be included in the 'ascent' metric for images, or am I just introducing a bug that happens to offset the one I'm trying to fix?
Source-Repo: https://github.com/servo/servo
Source-Revision: 0688488a7fd3caee423968b33d6c19d79f94d29a
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
Source-Repo: https://github.com/servo/servo
Source-Revision: a3821bf24094bf5bb2a9553e66b69da3b6430aa5
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: b876a54dce091e161b87340130446597dd864732
By definition of a weak pointer, these implementations cannot be safe.
Source-Repo: https://github.com/servo/servo
Source-Revision: 82be491fa318f742720dc0a31f6c1b24beb57a3d
Currently, we use UnsafeFlow and UnsafeLayoutNode, both of which are aliases
for (usize, usize) and thus interconvertible. This change should make it
clearer that the WorkQueue is not limited to one particular type.
Source-Repo: https://github.com/servo/servo
Source-Revision: 07a1e187f03484c5f326e48c4a5fed81c134d215
Currently only the end of the byte range is used, but I plan to use the full range in some follow-up work.
Fixes#6431. r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 26982cb547f479e1fbe9395b7fd9207078a6d8ee
