This was making `box-shadow` not show up in many cases, in particular,
but the effects were not limited to that.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 499d17f564d699e5e290e8a3859f64e7536827a7
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
This prepares for the rust upgrade currently being conducted.
Source-Repo: https://github.com/servo/servo
Source-Revision: e8fac3681b690adb0796b2a807ac95bd9c13597a
It is possible for a PaintTask to start exiting soon after sending new
buffers to the compositor. In that case, the compositor should return
the now unnecessary buffers to the PaintTask so that it can properly
free them.
To accomplish this, the compositor now keeps a hash map of paint task
channels per pipeline id. When a PaintTask exists, the constellation
informs the compositor that it can forget about it. Additionally, the
PaintTask should not wait for any buffers when the engine is doing a
complete shutdown. In that case, the compositor is already halted and
has simply let all buffers leak. We pipe through the shutdown type when
destroying the pipeline to make this decision.
Fixes#2641.
Source-Repo: https://github.com/servo/servo
Source-Revision: a31acffb0405b2c38b39c39c6d552f2ba79b6326
Note that I had to change some expectations to make them pass.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5d8ec549597de4af1008ee1395f89adbcf40fdb8
This fixes the following warning:
```
display_list/mod.rs:735:20: 735:30 warning: use of deprecated item: Use `Int::zero()` or `Float::zero()`., #[warn(deprecated)] on by default
display_list/mod.rs:735 let zero = Zero::zero();
^~~~~~~~~~
```
Source-Repo: https://github.com/servo/servo
Source-Revision: de3cff0e08bb93bad0c317ba4fe130a8a89cdb55
`str::to_string()` goes through a `Formatter`, `str::into_string()` is a direct copy and is apparently 5× faster.
This is a rebase of the boring and bitrot-prone parts of #4366.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9857ea26cb9ee262654bee97322dbbf373486bff
Together these improve a large number of sites: GitHub, Reddit, Wikipedia, etc.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 63a7742d834e9ed44421baa3ce218a5eabce58bf
I'm not sure how we want to handle Linux cursors, and GLFW has no
ability to set cursors (short of disabling it and managing it yourself).
If you test this in the wild you will probably hit #4357 until that PR lands.
Source-Repo: https://github.com/servo/servo
Source-Revision: e2267e0a0749e27046ee8a26ba514cc6865e0345
This property is used by approximately 55% of page loads.
To implement the line breaking behavior, the "breaking strategy" has
been cleaned up and abstracted. This should allow us to easily support
other similar properties in the future, such as `text-overflow` and
`word-break`.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 68ab18876bf4e210da26590420b9844b9cb0c92d
This assumes that there are no ligatures that span across multiple
words. Since we have a per-word shape cache, this is a safe assumption
as of now. I have left comments to ensure that, if and when this is
revisted, we make sure to handle it properly.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 98920b1315e7b867b293a56f5eb81784845f4a19
Groove and Ridge rendering shows a solid border when color is black, that is broken and the current patch will implement a similar behavior as Firefox.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74a57821f89aa637c4aa20e8757b2635c01578d
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
`invert` is not yet supported.
Objects that get layers will not yet display outlines properly. This is
because our overflow calculation doesn't take styles into account and
because layers are always anchored to the top left of the border box.
Since fixing this is work that is not related to outline *per se* I'm
leaving that to a followup and making a note in the code.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: d31237f3439e5e5d4055b3a9e53eaeee4f3cdf2c
Now that content box queries are made against the flow tree, we can
remove PseudoDisplayItems from the display list.
Source-Repo: https://github.com/servo/servo
Source-Revision: d988d01dd01c4e7e1503667cdfe91d4663e2c916
This exposed some problems in our clipping logic, which was never
properly rewritten for the stacking context reform. The clipping code
worked in terms of a stack of clips, but the new stacking context code
has no concept of a stack of clip regions. Fixing that in turn exposed
some flaky/incorrect tests:
* `borders` had an incorrect reference image, as far as I can tell.
* `negative_margins` had some stray pixels, fixed by changing the text.
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: 40c706b42d9d29ef58913f22da49159796e1b81b
#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 will avoid drawing Arcs if there's no border-radius property set.
Fixes#4127
Source-Repo: https://github.com/servo/servo
Source-Revision: 736d542beb82218e4c4c6eeb8116bc95334d9115
This adds the infrastructure necessary to support stacking contexts that
are not containing blocks for absolutely-positioned elements. Our
infrastructure did not support that before. This minor revamp actually
ended up simplifying the logic around display list building and
stacking-relative position computation for absolutely-positioned flows,
which was nice.
This will need this PR: https://github.com/servo/rust-azure/pull/112 I have not updated the Cargo.lock file yet because I want the merge commit.
r? @glennw
f? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 68c90e27970808bddcb8c8a4e782bd4405e67a5c
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
This implements a subset of the CSS `linear-gradient` property per the
CSS-IMAGES specification:
http://dev.w3.org/csswg/css-images-3/
The full syntax is parsed, but only the beginning and end color stops
are used, and gradients are clamped to the nearest 90 degrees. It should
not be architecturally difficult to add the remaining pieces, but in the
interests of bounding the size of this patch that work has been left to
follow-ups.
Improves GitHub.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: ed22c9b35b64ccf7a68ed4f26b1eecfa39996efd
I'm sad to say that this improved performance significantly. A lot of
this win is due to the Rust compiler not being smart about not zeroing
objects out if it doesn't need to.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 5e71087ae96a4dcff7f09ab2b9b56df9f3eba595
One part (of 8!) of css font family disambiguation is that font families should
be matched case-insensitively.
This patch implements that. Once it lands, a bug needs to be filed to do lowercasing
properly (as a string, instead of char-by-char -- it's a unicode thing).
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a88a3242cf85c807875883aeb14d113a1a27212
During debugging, I found it useful to hook all task creation in a
central location, and util::task was the perfect place for it.
r? @pcwalton (or maybe someone else, I'm kinda sending you a bunch of
reviews today because I don't know who better to give them to)
Source-Repo: https://github.com/servo/servo
Source-Revision: ff06be91ebe770290ba912ee71a303810aa62cea
The only real user-visible change this effects is to trim URLs to 30 characters so they don't make huge lines on the terminal.
r? @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: a6f0159cb85e3b84a826c41ae5ad1b6aea09d7cc
We've discussed this some and I think there's consensus to do it as a
pragmatic decision for now. CPU painting is more stable, especially with
buggy drivers, and faster (because we aren't caching the necessary
OpenGL objects yet and possibly for other reasons), so it provides a
better "out of the box" experience for newcomers to Servo who don't know
to pass the `-c` option. This patch continues to reftest both Skia and
Skia-GL out of a desire to keep options open. Skia-GL remains a
first-class citizen.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: 1fd7650de504611016d1ce10a5af2c1a4e0f6b9c
This is a grab bag of performance improvements that significantly improve style recalculation, layout, and painting on a few static pages.
Let me know if you'd like me to split this PR up.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 156ca98236a57ee52ff5b68741bc7783ba073612
