This patch set introduces the `--multiprocess` (`-M`) switch. Right now, all it does it cause display lists to be serialized, but eventually it will cause actual processes to be spawned.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: c4480b5d0309acc7f154166b91992f73a85de57f
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
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
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
Source-Repo: https://github.com/servo/servo
Source-Revision: 10b0d8c537c226400a617d28e8a060f9ca53d242
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
This will allow reporting of memory usage by FreeType instances, which
are measured in the MiBs for LayoutWorker threads.
This change also makes FreeType allocations happen with jemalloc instead
of the system malloc, which is a good thing.
Finally, the change documents some dubiousness involving
FontContextHandle.
Source-Repo: https://github.com/servo/servo
Source-Revision: fdeebf86a1424e9fffa122efa08fe397f6e7cd7d
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
Fixes#5914
r? @nnethercote for the gfx changes
r? @kmcallister or @jdm for the plugin
Source-Repo: https://github.com/servo/servo
Source-Revision: 2ca606aaba432741ce4e8274835f26db3a3581fc
Example output from the memory profiler:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
The buffer maps aren't huge, but they're worth measuring, and it's good
to get the memory profiler plumbing into PaintTask.
Source-Repo: https://github.com/servo/servo
Source-Revision: 10127d6b5a71ee8927413ab746300e32a54b079d
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
A rebuild after touching components/profile/mem.rs now takes 48 seconds (and
only rebuilds `profile` and `servo`) which is much lower than it used to be.
In comparison, a rebuild after touching components/profile_traits/mem.rs takes
294 seconds and rebuilds many more crates.
This change also removes some unnecessary crate dependencies in `net` and
`net_traits`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77f653da2c4120ea7ac1a946d97fc70059d513d4
There are several optimizations here:
* We make font families atoms, to allow for quicker comparisons.
* We precalculate an FNV hash of the relevant fields of the font style
structure.
* When obtaining a platform font group, we first check pointer equality
for the font style. If there's no match, we go to the FNV hash. Only
if both caches miss do we construct and cache a font group. Note that
individual fonts are *also* cached; thus there are two layers of
caching here.
15% improvement in total layout thread time for Facebook Timeline.
r? @glennw (since you last worked on `get_layout_font_group_for_style()` IIRC)
Source-Repo: https://github.com/servo/servo
Source-Revision: ba0d28e0023fce2003d64b9caf97fcdbeb7cdb28
- Most of util::memory has been moved into profile::mem, though the
`SizeOf` trait and related things remain in util::memory. The
`SystemMemoryReporter` code is now in a submodule
profile::mem::system_reporter.
- util::time has been moved entirely into profile::time.
Source-Repo: https://github.com/servo/servo
Source-Revision: d1268ec9c6633684270015e7b2619181aeb47b8b
Ready for review.
Final link step on android fails, but we know how to fix it and will add it to this branch soon.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2cc08f289ab909de44fa09a07b2c43b70ce379b9
This used to conflict with the util crate from the standard library, which
has long since been removed.
The import in layout has not been changed because of a conflict with the
util mod there.
Source-Repo: https://github.com/servo/servo
Source-Revision: 27e0f16407629422b5e047e067d458142372c97e
`blur` and `drop-shadow` are not yet supported, because the
`text-shadow` PR makes some fundamental changes to blur rendering that
are needed first.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: ffdbf29db28ba334e8baf8d35141b5e8ad289459
Notes:
* This adds `#![allow(missing_copy_implementations)]` to components/*/lib.rs. I'm not sure how to approach the missing Copy warnings (are there things for which Copy should NOT be implemented, and how can I tell?) so I stuck this in to make life easier when looking through the warnings. I can easily remove this if necessary.
* This leaves the following type of warnings, which I couldn't figure out how to approach (I'll investigate it later if no one else wants to).
```
css/matching.rs:72:23: 72:35 warning: use of deprecated item: Use overloaded core::cmp::PartialEq, #[warn(deprecated)] on by default
css/matching.rs:72 this_as_query.equiv(other)
^~~~~~~~~~~~
css/matching.rs:95:10: 95:49 warning: use of deprecated item: Use overloaded core::cmp::PartialEq, #[warn(deprecated)] on by default
css/matching.rs:95 impl<'a> Equiv<ApplicableDeclarationsCacheEntry> for ApplicableDeclarationsCacheQuery<'a> {
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 0793137631cbe4ebbff8fb85639206ce8e41bbb7
In particular, this contains changes to qualify enums where rust will require it, and to stop using some features that will be removed.
Source-Repo: https://github.com/servo/servo
Source-Revision: ba8cf6b0e6145265f9472d4855f078d8b5943fe7
Together these improve a large number of sites: GitHub, Reddit, Wikipedia, etc.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 63a7742d834e9ed44421baa3ce218a5eabce58bf
The ligature disabling code has been manually verified, but I was unable
to reftest it. (The only way I could think of would be to create an
Ahem-like font with a ligature table, but that would be an awful lot of
work.)
Near as I can tell, the method used to apply the spacing (manually
inserting extra advance post-shaping) matches Gecko.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 914f27263d60ffcbe2fd1f9e47a48e3aa3f1cd76
#4275
* This changeset rename "render"/"rendering" to "paint"/"painting" under `components/`.
* This does not rename words which are used as general browser's working.
* So this doesn't change `reftest.rs`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0b486b12109ab765ecee4cbcc684e5d99e8ad5ad
This implements the scheme described here:
https://groups.google.com/forum/#!topic/mozilla.dev.servo/sZVPSfPVfkg
This commit changes Servo to generate one display list per stacking
context instead of one display list per layer. This is purely a
refactoring; there are no functional changes. Performance is essentially
the same as before. However, there should be numerous future benefits
that this is intended to allow for:
* It makes the code simpler to understand because the "new layer needed"
vs. "no new layer needed" code paths are more consolidated.
* It makes it easy to support CSS properties that did not fit into our
previous flat display list model (without unconditionally layerizing
them):
o `opacity` should be easy to support because the stacking context
provides the higher-level grouping of display items to which opacity
is to be applied.
o `transform` can be easily supported because the stacking context
provides a place to stash the transformation matrix. This has the side
benefit of nicely separating the transformation matrix from the
clipping regions.
* The `flatten` logic is now O(1) instead of O(n) and now only needs to
be invoked for pseudo-stacking contexts (right now: just floats),
instead of for every stacking context.
* Layers are now a proper tree instead of a flat list as far as layout
is concerned, bringing us closer to a production-quality
compositing/layers framework.
* This commit opens the door to incremental display list construction at
the level of stacking contexts.
Future performance improvements could come from optimizing allocation of
display list items, and, of course, incremental display list
construction.
r? @glennw
f? @mrobinson @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 397d8138e7b27541faf03d9635d7648416da4a75
