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
Multiprocess mode is enabled with the `-M` switch, and sandboxing is
enabled with the `-S` switch.
Rebase of #6884.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8b39b9afed6ef8a3d7d3e6609fd301a37825d3e1
When new_actual_size < old_actual_size, there is an overflow panic since we're using usize. This breaks Reddit for me.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8950345e0e2c803cfa87105374dfdb30a550cfe0
I created draft. I'm not sure if we need any units conversion in PaintContext. There is also strange 'clear' method, we use PagePx origin and ScreenPx size is it OK?
Source-Repo: https://github.com/servo/servo
Source-Revision: 8d8ffa8265d67e0ec89cf2d37d1c549b47187cca
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
Source-Repo: https://github.com/servo/servo
Source-Revision: da25b8c848886d2fc875008de5adcaf13d7c9e99
Sometimes positioned content needs to be layered on top of stacking
contexts. The layer synthesis code can do this, but the current design
prevents it because stacking contexts are stored in a separate struct
member. In order to preserve tree order, mix stacking contexts into the
positioned content list, by adding a new StackingContextClass
DisplayItem. Such items do not have a base DisplayItem.
In some ways this simplifies the code, because we no longer have to
have a separate code path in the StackingContextLayerCreator.
Source-Repo: https://github.com/servo/servo
Source-Revision: 86e3add8fdc35fc6980bb63695781925607437b8
Before passing these layers to the paint task, expand them to pixel
boundaries. This ensures that subpixel edges of the layer will not be
clipped away and helps prevent rounding issues with layer contents.
Fixes#8166.
Source-Repo: https://github.com/servo/servo
Source-Revision: 94ca87e7ddc07160b9205c0112b60b0a951f0742
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
Layers that are composed of several stacking contexts that need to be
rendered on top of other layered content need synthesized layers.
Previously, these layers were placed into a stacking context that was
the same size as their parent. This patch creates a new type of
PaintLayer which simply holds a display list. The layer is sized to the
bounds of the DisplayList and its children are positioned relative to
the parent stacking context.
This will also be useful in the future, when items outside of
StackingContexts are given their own layer for render order purposes.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6d52bdf4ffd5479780df4a3fb0ff07bd7378720e
Only supported in WebRender (with my upcoming PR) for now.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 5eb1c04e7854d932c0d63f9e5ed4d54ee43deb9b
This fixes an issue whereby normal text would intermittently be rendered as
small-caps and vice versa.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0b397db77b87f02d1742efd71f526ba6e89197b
This doesn't change any functionality, but it's the first step towards removing SubpageId.
Adding this change now will allow us to gradually change over code referencing subpage id rather than in one massive PR.
Introduces a namespace for pipeline ID generation - there is a namespace for the constellation thread, and one per script thread.
Source-Repo: https://github.com/servo/servo
Source-Revision: 098bdb5f22500a6e856b085a1140090f63ef8645
StackingContexts are added to layers when it is necessary to maintain
their ordering on top of other layered StackingContexts. Instead of
tracking the information about a layer scattered around into different
structs, combine it all into LayerInfo. LayerInfo will be used in the
future to hold layer information for DisplayItems that are layerized
independently of StackingContexts.
Source-Repo: https://github.com/servo/servo
Source-Revision: 27d468b6674b81c396aa0a13d8fe9eb410c12d6e
Depends on servo/rust-azure#201 and pcwalton/ipc-channel#10.
Closes#7422.
r? @mbrubeck (don't r+ until the upstream dependencies have landed)
cc @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e2048d57c4c0602c5a6b82db8cb76e6c3e5467fa
This will allow us to hit test into DisplayLists that are not directly
contained in StackingContexts, but instead are children of PaintLayers.
It also makes things slightly simpler.
Source-Repo: https://github.com/servo/servo
Source-Revision: b1d9f438b79743e03cb5b81a0e36f336943e940e
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
Depends on servo/rust-harfbuzz#53 and introduces a dependency on the new servo/unicode-script crate. r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: a144d086d911375f8d5674ac90ff55a9dcaf0cda
When one border is 0px and the other is >0px then the border corner
drawing code panics when computing the values to use in drawing the
border corner arcs.
This fixes that bug and makes the `draw_corner` function more robust
by explicitly passing an enum, `BorderCorner`, naming which corner is
being drawn e.g. `BorderCorner::TL`.
Add a ref test,
`border_radius_zero_sizes_a.html/border_radius_zero_sizes_ref.html`.
Fixes https://github.com/servo/servo/issues/7700.
r? @pcwalton or @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 4d1be2f56cd7a37c4c803ba12733fca55b57d4de
This will be useful when PaintLayers that contain DisplayLists instead
of StackingContexts need to draw themselves. This is a simple
preparatory refactoring and doesn't change any behavior.
Source-Repo: https://github.com/servo/servo
Source-Revision: 09b970af4aeba749146a9a9215e346653016672b
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
cgaebel had a TODO for a css twitter fail whale reftest, which depended on elliptical border-radius support.
I didn't see any feasible way other than a reference image for border_twitter_fail_whale_b.html.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: c91c0188f279b9d7edf706fc7ad3111948156ed6
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
Source-Repo: https://github.com/servo/servo
Source-Revision: cf13e806fe2f4cf5ad5f30efd16d7bd3f501f8b3
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
Use box tree characters to make DisplayLists easier to scan when
printing them out.
This is what the output looked like before:
```
#### start printing display list.
"####" Stacking context at Rect(800px×608px at (0px,0px)) with overflow Rect(800px×608px at (0px,0px)):
#### SolidColor(0,0,0,0). Rect(800px×608px at (0px,0px))
#### SolidColor(0,0,0,0). Rect(784px×0px at (8px,0px))
#### SolidColor(0,0.5019608,0,1). Rect(100px×100px at (0px,0px))
#### Child layers list length: 1
"########" Stacking context at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
######## SolidColor(1,0,0,1). Rect(100px×100px at (0px,0px))
######## Child layers list length: 1
"############" Stacking context at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
```
This is what it looks like after this patch:
```
┌ DisplayList
│ ├─ Layered StackingContext at Rect(800px×608px at (0px,0px)) with overflow Rect(800px×608px at (0px,0px)):
│ │ ├─ Block Backgrounds and Borders
│ │ │ ├─ SolidColor rgba(0, 0, 0, 0) @ Rect(800px×608px at (0px,0px)) (7f926f46f1f0)
│ │ │ └─ SolidColor rgba(0, 0, 0, 0) @ Rect(784px×0px at (8px,0px)) (7f926f46f2e0)
│ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ │ ├─ Backgrounds and Borders
│ │ │ │ └─ SolidColor rgba(1, 0, 0, 1) @ Rect(100px×100px at (0px,0px)) (7f926f46f310)
│ │ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ │ ├─ Backgrounds and Borders
│ │ │ │ └─ SolidColor rgba(0, 0.5019608, 0, 1) @ Rect(100px×100px at (0px,0px)) (7f926f46f3a0)
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e9a888f1ac58866833418ee5e8253358918b741
Thanks to @Jinwoo-Song for the original commit, which I just rebased and cleaned up. Fixes#6237.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6a12f00d6d392651bae10365b4c806f36d704b21
Hi guys,
I just gave a big pass of RFC-0344 as per issue #6224 .
Pretty much renamed all the get_* fn that were used to fetch values.
I hope I didn't rename too much.
As said in the issue discussion, I didn't touch at the scripts folder so we keep the unsafe ones pretty explicit.
I've ran the whole pass of test, everything seems to be still working right :).
Please give feedback on this PR.
Thanks for looking into it.
Source-Repo: https://github.com/servo/servo
Source-Revision: b05f4aa3aa3085e65cb75433ae37bf272216d033
In advance_for_char_range add a fast SIMD code path for the the common
case where there are no detailed glyphs.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: c83825938346f794790bcd1343b7375e9e34f443
In to_nearest_azure_rect when rounding to pixel coordinates, maintain
the invariant of rect non-overlap (if before rounding two rects don't overlap).
The previous code rounded the rect top left corner to the nearest pixel with
the size rounded to the nearest pixel multiple which can violate the
non-overlap condition, e.g.
10px×9.60px at (0px,6.6px) & 10px×9.60px at (0px,16.2px)
would round to
10px×10.0px at (0px,7.0px) & 10px×10.0px at (0px,16.0px), which overlap.
Instead round each corner to the nearest pixel.
For rects that dont need to satify the non-overlap condition and with
width or height between 0.5px and 1px, rounding each rect corner to the
nearest pixel can yield an empty rect e.g.
10px×0.6px at 0px,28.56px -> 10px×0px at 0px,29px.
For this scenario a new function to_nearest_non_empty_azure_rect
rounds the rect top left corner to the nearest pixel and the rect size
to the nearest pixel multiple. It's possible for non-overlapping rects
after this rounding to overlap.
This should fix https://github.com/servo/servo/issues/7184 "rounding ...borders not to be visible", without breaking https://github.com/servo/servo/issues/7152 "Underlines less than 1px high sometimes invisible".
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: f29ddb4b5d5eed595df37fa989511d2cb3aa8dfd
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0381c732569b9abe6282c6c750533bc271a2019
