This fixes about 130 clippy lints. Let me know if i should split up the commit.
I wasn't sure about some of the changes, especially map_or instead of map(...).unwrap_or(...) and if let instead of single arm match were not always a strict improvement in my opinion, but i'll leave that decision to the reviewer :)
There are about 150 lints left which i thought were clippy bugs or i didn't know how to fix.
cc @Manishearth
Source-Repo: https://github.com/servo/servo
Source-Revision: 9da739acefc7d1776bf727c8bf782eb79f241028
This is a proposed in servo/servo#8792 clean up.
Fixes#8792.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2dbc314e2dec39b8798d4e922dd5220d32083b56
This gets us to where we need to be in order to write a Gecko implementation of the layout wrapper and have things Just Work.
Note that this is somewhat more than we need for just running the style system. But there wasn't a clean place to cut, and I thought it was a good idea to just do a complete job on it now, which may save us effort and mismatches in the long run.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1f732cfbb404bfd96c3ed3f71c4b9900b7ffbba2
The RECONSTRUCT_FLOW restyle damage bit shouldn't apply to newly
constructed flow tree elements. It is explicitly removed for Flows, but
not for Fragments. This causes RECONSTRUCT_FLOW to bubble up to Flows
that contain any Fragments at all. Instead explicitly remove the
RECONSTRUCT_FLOW bit when creating a new Fragment.
There isn't a good way to test this currently, but all tests should
continue to pass.
Source-Repo: https://github.com/servo/servo
Source-Revision: d50b87edeca45fdca1cf491e6a9a18011fe0c120
Updated string_cache to 0.2, and updated the dependencies that depend on string_cache.
Removed references to string_cache_plugin.
Import atom! and ns! from string_cache.
Replaced ns!("") by ns!().
Replaced ns!(XML) and co by ns!(xml) and co.
Replaced Atom::from_slice by Atom::from.
Replaced atom.as_slice() by &*atom.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 188fa9378c103093f1f8dac24bff0d9d237fd2bc
Use the PrintTree utility to improve the readability of flow tree
dumps. Blocks and fragments are now split over two dump levels, because
otherwise they are impenetrable. Also start printing the restyle damage of
fragments.
Source-Repo: https://github.com/servo/servo
Source-Revision: a2330f494316926dca9f64431d8357a093143d7d
Canvas is currently given a layer at the stacking context level.
Instead it's DisplayItem should be given a layer directly. This fixes
painting order issues where canvases are painted on top of other
positioned content that is later in tree order. It always simplifies
the code a bit.
Source-Repo: https://github.com/servo/servo
Source-Revision: 22a6884a671da0434fe2b3bf30f50b9133d4c70b
Instead of always promoting iframes to StackingContexts, integrate them
into the display list. This prevents stacking bugs when
non-stacking-context elements should be drawn on top of iframes.
To accomplish this, we add another step to ordering layer creation,
where LayeredItems in the DisplayList are added to layers described by
the LayerInfo structures collected at the end of the DisplayList.
Unlayered items that follow these layered items are added to
synthesized layers.
Another result of this change is that iframe layers can be positioned
directly at the location of the iframe fragment, eliminating the need
for the SubpageLayerInfo struct entirely.
Iframes are the first type of content treated this way, but this change
opens up the possibility to properly order canvas and all other layered
content that does not create a stacking context.
Source-Repo: https://github.com/servo/servo
Source-Revision: 11d23a41b31c2b2846d1e9c6b40e87ba7e2a095f
This is mostly straightforward. I had to modify a couple of places
which were accidentally discarding whitespace.
Fixes#1513.
This fixes some relevant tests from the CSS testsuite... but a lot of
them are either manual, or don't pass because of unrelated issues. (For
example, white-space-mixed-002 renders correctly, but
white-space-mixed-002-ref doesn't because of a float bug.)
I'd appreciate any suggestions for how to go about adding tests for this.
Source-Repo: https://github.com/servo/servo
Source-Revision: c3ab71109ee2ffcc31b40890f4c6739d8f5b1333
When a stacking-context is not positioned, its z-index should be
ignored. This is per CSS 2 9.9.1. The only exception to this is when
the z-index is applied to an element with display: flex | inline-flex.
inline-flex does not appear to be implemented at this time so we only
do this for flex.
Source-Repo: https://github.com/servo/servo
Source-Revision: 90dd3cdc095d7bf54435f0fcb8a6fe134b00fc24
This makes use of the new functionality that allows iframes to generate their own pipeline IDs in order to remove any knowledge of subpage ids from the compositor.
(This is the first of several commits removing subpage from parts of servo).
Source-Repo: https://github.com/servo/servo
Source-Revision: 1d617f332edd0036ca4cbc3890f1f44f57597906
Have Fragment::create_stacking_context understand which stacking
contexts need layers and which do not. This simplifies the way it is
called and eliminates a bunch of code.
Source-Repo: https://github.com/servo/servo
Source-Revision: bb7742eecf00dd4cb5bfcbafcae36d928a5b8b89
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that only the size of an iframe is
determined during layout, and the position is determined by the
compositor. Layout layerizes iframes and marks the iframe layers with
the appropriate subpage ID so that the compositor can place them
correctly.
Closes#7377.
Source-Repo: https://github.com/servo/servo
Source-Revision: a0cb657fe80859dd8862361631268479d1045432
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
Known issues:
* The caret doesn't show up if there's no text present, because we don't create text runs in that case. This should be a followup.
* Text runs don't support decomposing ligatures into their constituent subglyphs for advance computation, so the caret won't appear inside a ligature. This is a text run bug.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 6cd098da302db85975d0967ddee836f04eae3bd5
Removes the long space before the site-specific drop-down in the Google SERPs.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: aeb8dce2d914808e4cdb8589d19ee9968897ed94
Elided almost all the lifetimes and removed needless returns. Mostly done by sed + manual fixes.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: c2c2646d37614ece5869af861993c3d619f6e003
* The code that attempted to strip out borders that span multiple
fragments in the same element could go wrong if fragments were
stripped out due to text clumping or whitespace stripping. This patch
rewrites that code to maintain flags in the inline fragment context
specifying whether the node is the beginning or end of the element.
Not only is this easier to maintain, it's closer in spirit to what roc
originally suggested two years ago: it's isomorphic to "begin element,
end element" markers for inline layout.
* Padding and margins for spans containing inline-blocks are now
properly handled via a division of labor between the `InlineBlock`
fragment and the `BlockFlow` that represents the inline-block.
* Unscanned text fragments may not be joined together into a text run if
borders, padding, or margins separate them.
Because Servo now matches the rendering of Gecko and WebKit on the
`input_button_margins_a` reftest, I had to modify it to add some
vertical alignment.
The combined effect of all of these fixes places "Advertising" on the
right place on google.com.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 8bbace7815b489e1b87df2ec496e65e78721d929
This is #7185 with one commit added to make it build merged with master, which got support for the `ch` unit in the meantime.
Source-Repo: https://github.com/servo/servo
Source-Revision: a547ae6826cf171c42b090408a4c20d58d1829d9
Improves the position of the down arrows on google.com SERPs.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: e46499a5dfd9189fc439c228d9a5fe23dfec0d7d
This necessitated changing overflow to be calculated by the parent flow
if relatively positioned children are present. That is because the
overflow regions cannot be calculated without knowing relative offsets,
which themselves cannot be calculated without knowing the parent size
(because of percentages). To accomplish this without sacrificing
parallelism in the non-relative case, this patch splits overflow into
"early" and "late" computation. Late overflow computation cannot be
parallelized across children, while early overflow computation can.
Makes the "Apple Music" text show up over the full-bleed promotional
background on apple.com.
r? @SimonSapin -- would appreciate a look over the iframe test case that was changed.
Source-Repo: https://github.com/servo/servo
Source-Revision: dcaf66397a06246b9b4fdca3a10af1508a11f1e8
Fixes placement of the header on espn.go.com.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: a1cd27e6a3b961129fd4710513cc29e4f7c9cc67
…so that it can be activated when we're forcing
the creation of extra layers due to positioned descendants that
themselves have layers.
The newly failing tests were tests that accidentally passed due to
incorrect stacking order.
Closes#7281.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 7945c174a6f90f3809a6d60f392a94e0ce10f021
Improves imgur.com and Fast Company articles.
This change made `min-height-106.htm.ini` fail because the thing it was testing
for never worked: we were relying on the incorrect stacking order of `position:
relative` to get the green square to show up.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 23657484adcbd93ee4fc5b274e2b5500a09107a6
Several issues are addressed in this commit:
* Inline flows now bubble up their absolute descendants instead of
making the inline flow the containing block for them. (In the future,
we will need to make the inline flow *sometimes* be the containing
block for them, but for now it improves sites to unconditionally
bubble up.)
* Fragments now look at their inline fragment context to determine
whether they are positioned.
* Inline flows now push the stacking-relative position of the absolute
containing block down to their inline-block fragments.
* Inline absolute hypothetical fragments can be containing blocks.
* Fixes the logic in
`containing_block_range_for_flow_surrounding_fragment_at_index`. The
condition to determine whether fragments are positioned was inverted!
* `Descendants`/`AbsDescendants` has been refactored in order to become
more friendly to inline absolute containing blocks in the future.
Improves the inline position of the green drop-down arrow in the Google
SERPs. (The block position is still wrong.)
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: d654841288ad6c7d4f8d7da3c68d04ef7df2c241
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
There were two bugs here: (1) relative position applied to
scanned/unscanned text fragments independently of the container element
that applied that relative position, causing double-counting; (2)
relative position applied to inline block fragments independently of the
wrapped block itself, causing double-counting.
Closes#7067.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 0bfde427e6a77d09d75b5a6e228c7b25f063395f
This patch makes Servo unconditionally strip whitespace before text run
scanning (assuming that the `white-space` property allows it). Whitespace
stripping during reflow is now only used for handling whitespace at the ends of
lines; reflow now never attempts to handle ignorable whitespace.
Many CSS tests pass now. There are some new failures, however.
The following reference tests now fail due to a pre-existing bug whereby
whitespace is used to calculate the position of inline hypothetical boxes for
elements with `display: inline; position: absolute`:
* `absolute-replaced-height-036.htm`
* `vertical-align-sub-001.htm`
* `vertical-align-super-001.htm`
The following reference tests fail due to a pre-existing bug whereby we don't
handle `font-size: 0` properly in inline reflow:
* `font-size-zero-1.htm`
* `font-size-zero-2.htm`
The following reference test fails due to the fact that it relied on our
incorrect insertion of whitespace to make room for the black background:
* `inline-formatting-context-007.htm`
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 7dc83e7820df43b1b617ae8dcf661398b0bd0842
Avoids a needless wrapped line in the repository name on GitHub.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: da06c2dda096bd5e2a8959c102c315f9838ed465
It's not possible to correctly determine during the css cascade whether the container height
is explicitly specified. Additionally, the spec https://drafts.csswg.org/css2/visudet.html#the-height-property says this should affect the *used* height, rather than the computed height.
This significantly improves the layout in #6643.
Source-Repo: https://github.com/servo/servo
Source-Revision: 028707f5cd3263fd1476669207f67d5b9d5d4806
StrExt::slice_chars is deprecated and will be removed in Rust. This
lifts the implementation from Rust libstd and puts it in util::str.
This fixes a bunch of deprecation warnings in Servo.
Source-Repo: https://github.com/servo/servo
Source-Revision: a54404c92180b839d2cf089d9ec9a6afe8bd5ba3
It's not quite done but can probably be reviewed anyway.
I still need to finish up a few of the ToCss impls, I just got lazy and wanted to make sure things worked.
The computation of the used values is definitely not right, I'm going to investigate that.
Source-Repo: https://github.com/servo/servo
Source-Revision: acbca7b3aaf18866f7a1a79d9684149897bf4305
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
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
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
`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
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
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
--HG--
rename : servo/components/gfx/color.rs => servo/components/gfx_traits/color.rs
Fixes sites that use spacer gifs for table layout, such as the comments
page on Hacker News.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 49b73c0bfe50366e767525f9f90c5aa348f68f18
* Stop double-counting border and padding for inline-block fragments.
(Test case: `inline_block_border_intrinsic_size_a.html`.)
* Take clearance into account when determining intrinsic widths of
blocks containing floats.
Improves the Amazon headers.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 7b87085c1880c60aa3be5b3ec4572a0d93fd5537
* Fix queries involving stacking contexts
* The code was double accumulating stacking context origins.
* Handle queries of inline elements.
* The node addresses being compared were incorrect (CharacterData vs. Span)
* Handle ScriptQuery reflows correctly.
* The layout task was skipping the compute absolute positions traversal, so failed before window.onload.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5f6a740190e1e5912d84162c92c6b79365df165a
Fixes#5300, which it is a rebase of.
Known issues:
* Collapsed borders do not correctly affect the border-box of the table
itself.
* The content widths of all cells in a column and the content height of
all cells in a row is the same in this patch, but not in Gecko and
WebKit.
* Corners are not painted well. The spec does not say what to do here.
* Column spans are not handled well. The spec does not say what to do
here either.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8a4555cc53bc1bbb21a08eb6f010cb1215034419
Fixes the "jumpiness" seen on the Google home page, Wikipedia, and many
other places.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 211ee668fae7f619ac7e09abd776a6f45fc40052
* Simpler image cache API for clients to use.
* Significantly fewer threads.
* One thread for image cache task (multiplexes commands, decoder threads and async resource requests).
* 4 threads for decoder worker tasks.
* Removed ReflowEvent hacks in script and layout tasks.
* Image elements pass a Trusted<T> to image cache, which is used to dirty nodes via script task. Previous use of Untrusted addresses was unsafe.
* Image requests such as background-image on layout / paint threads trigger repaint only rather than full reflow.
* Add reflow batching for when multiple images load quickly.
* Reduces the number of paints loading wikipedia from ~95 to ~35.
* Reasonably simple to add proper prefetch support in a follow up PR.
* Async loaded images always construct Image fragments now, instead of generic.
* Image fragments support the image not being present.
* Simpler implementation of synchronous image loading for reftests.
* Removed image holder.
* image.onload support.
* image NaturalWidth and NaturalHeight support.
* Updated WPT expectations.
Source-Repo: https://github.com/servo/servo
Source-Revision: ac0645c2363b5a6ea3930b0857b3a27f1b6d033f
@jdm @ecoal95 I'm working on making VR happen in the Browser and I want to bring to Servo the [webVR APIs](https://github.com/MozVR/webvr-spec/blob/master/webvr.idl) we already have in Gecko. Before anything happens we need a working implementation of WebGL (and also the [fullscreen API](https://fullscreen.spec.whatwg.org/)). My implementation is very basic and probably naive (I just recently started to contribute to Servo). My patch is just a starting point:
- It only implements ```clearColor``` and ```clear``` methods of the [WebGL spec](https://www.khronos.org/registry/webgl/specs/latest/).
- It uses the readback strategy that ```canvasRenderingContext2D``` is using (The webgl task paints stuff independently on it's own buffer and the compositor task request the pixels back to the webgl task when it needs them) I'm sure there are much better ways to handle this. Latency and FPS are critical in VR so we have to figure out the fastest way to push pixels to the screen. I've read something about layerizing the canvas but I'm still not sure what that even means :)
- There's an included test you can try ```./mach run tests/ref/webgl-context/clearcolor.html```
@ecoal95 I know you'll be working on this for the next three months. With a foundation in place we will be able to make quick progress in parallel. This is exciting!
Source-Repo: https://github.com/servo/servo
Source-Revision: e4b620ea54c94e03095e4108bce94ec750416bba
Before this change, Servo used one code path that computed the position
of flows with `position: static` or `position: relative` and another
separate code path that computed the position of flows with `position:
absolute` or `position: fixed`. The latter code attempted to duplicate
the former code to determine the static position of hypothetical boxes,
but this was both fragile and incorrect in the case of hypothetical
boxes nested inside floats. In fact, it's impossible to determine the
static position of an absolute flow relative to its containing block at
inline-size assignment time, because that static position could depend
on a float that cannot be placed until block-size assignment!
This patch changes block layout to use the same code path for static
positioning of regular flows and static positioning of absolute flows
where applicable. This both simplifies the code and improves its
efficiency, since it allows the `hypothetical_position` field and
`static_block_offsets` data structure to be removed. Moreover, it
improves correctness in the above case (which the new reftest checks).
This allows the sidebar in Facebook Timeline to be positioned properly.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: bdcf606f4802e5b1ab3ee251b45ee1e81800359a
This allows things like `<sup><span>Foo</span></sup>` to work and
improves Wikipedia.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: d7b6961104b517a22e01c192d4bb6a7ad5934ce8
Basically, the easiest way to describe the effect of this change is "float placement takes line height into account". It didn't before, which could lead to lines overlapping floats or floats taking up too much vertical space.
Improves Wikipedia.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: d8507cce8c3969a08974f44a9f397e75cbe3131d
This fixes a lot of "jumpiness" and removes the `new_line_pos` stuff.
Closes#2260.
r? @mbrubeck
cc @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: d3478954fd8e3a8374104984efb91a918b5dbb7e
50% layout improvement in a photo gallery demo I'm working on.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a9f29f3824479da357d5cded2dc0847e6854813
Table layout code has been refactored to push the spacing down to
rowgroups and rows; this will aid the implementation of
`border-collapse` as well.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e811229bae6b338fabcd7df602079730c942889
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
Reconstructed from #5138 via raw diffing.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: fd1bb49a65dd998c8ef9890a1576aaf62ddfdba1
...and vice-versa. This is not a complete fix for all mixed-direction layout cases, but it fixes enough problems to make some simple test cases pass, like tha attached reftest.
There are FIXME comments for many of the remaining issues. In particular, this does not yet handle RTL layout of fixed/absolute elements, nor does it completely fix the overconstrained_block reftest.
r? @SimonSapin or @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 2df4dd9e098671fdbe2951f6669473e7737d6ed3
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
Moved from #4544, because Critic.
Fixes#4544.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5cd6316addc1acf145ed3220719387ef6ef08d2f
Inline fragments that are part of a text run don't have interior borders.
So don't draw interior borders or include them when calculating positioning.
Fixes https://github.com/servo/servo/issues/4658, where multiple text nodes that are adjacent have distinct borders.
r? @Ms2ger, @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: b2f099026a8c649daf063dc7e119a514c2680697
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
--HG--
rename : servo/ports/gonk/build.rs => servo/support/rust-task_info/build.rs
CSS-TEXT-3 § 7.3.
`text-justify: distribute` is not supported.
The behavior of `text-justify: none` does not seem to match what Firefox
and Chrome do, but it seems to match the spec.
Closes#213.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 7359f99f201a359aaebf334a1787d1975c9fa7d4
Only the one-value syntax is supported for now.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: c8e68fa45c43856f7ffbdde25b6e68571ad288bf
The Rust style guide suggests 100, but we have too many violations in the
tree already. This check can be tightened over time.
Source-Repo: https://github.com/servo/servo
Source-Revision: ee94b3e8bf659c847bda967700272f8f98fdb0cc
`background-blend-mode` is not yet supported because we don't support
multiple backgrounds yet.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: e6fe9f14092251b0d1a8c97473dda9b5d73679cd
Content of the canvas is drawn, tests/html/test_canvas.html now works.
Source-Repo: https://github.com/servo/servo
Source-Revision: da400a7a453eacf6f3089cc07e5dc61f385a0909
`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
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
Together these improve a large number of sites: GitHub, Reddit, Wikipedia, etc.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 63a7742d834e9ed44421baa3ce218a5eabce58bf
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 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
Instead of looking at the display tree, have ContentBox(es)Query consult
the flow tree. This allow optimizing away parts of the display tree
later. To do this we need to be more careful about how we send reflow
requests, only querying the flow tree when possible.
Fixes#3790.
Source-Repo: https://github.com/servo/servo
Source-Revision: c9089c45c4b7d40419233b48a192d85a8ad71c99
This is the last PR and most of the work for the maze solver and RoboHornet.
r? @glennw
cc @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 035ff19e4a5995989c5fd34928af2a6690bb8062
`layout::fragment` and `layout::block` were getting too big.
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: 01f6a8102dfbb7eaef564acf8891088011905b59
