This reduces some unnecessarily tight coupling, makes it clearer what these functions do, and may help avoid bugs where we would return from such a function without updating the relevant field.
It is also a precondition for some future experimentation I'm thinking of doing with this querying design.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3a254b7e20c37e4ce7b614abea9ebd4687c65f98
This isn't doing anything right now, and we're not even setting it properly
in dirty_impl the |dirty_subtree(self)| was causing us to hit the skip case
for step 3.
Source-Repo: https://github.com/servo/servo
Source-Revision: 50ec2353845bf2a3971d5b01db37d2c3741d3912
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
Translate <meta name=viewport> as according to [CSS Device Adaption § 9](http://dev.w3.org/csswg/css-device-adapt/#viewport-meta)
Note: as the PR currently stands, handling `<meta name=viewport>` elements always occurs. This is probably not desired for some contexts (e.g. desktop), but I'm unsure of how to conditionally handle elements based on that.
Source-Repo: https://github.com/servo/servo
Source-Revision: a7743052cad0387733c90940fa91733ede32772c
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
(#[cfg(debug)] is false in every normal servo configuration, and the
code in question doesn't compile.)
Source-Repo: https://github.com/servo/servo
Source-Revision: d4f5948294545860a88d6a266acaa4cf9b9ea1c6
There were two problems here:
(1) The animation state update function was only called when nodes were dirty or there were new animations.
(2) When all animations for a node expired, the entry from the hash table was not removed.
The result was that once an animation began, the compositor would be running as fast as it can forever.
Fixes#7721.
Source-Repo: https://github.com/servo/servo
Source-Revision: b4b3cedc10cec47d95880bfbe55f2dbc37cd910e
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
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
Support `var()` in shorthand properties, and fix various bugs.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 1b6d4daf85d672265824a014dba99c94c8c08814
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
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e0b010117889550effa3ad793e7ee8f9b692b40
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
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
Known issues:
* Display list optimization can sometimes optimize out elements that
should be shown. This affects the Enyo demo.
* The `overflow: scroll` container doesn't clip the inner layer properly
when borders, border radius, etc. are present.
* `overflow-x: scroll` and `overflow-y: scroll` don't work individually;
elements are scrolled all at once.
Note that multiple layers per stacking context aren't needed for the Enyo demo; rather the issue is that the height of the main area is being calculated incorrectly. (It looks like JS is measuring the height and poking in an explicit value that is too tall.)
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: b05b02e11fb849e1f0153d009d8fcf0501ace8dc
Large improvement in page load times, especially in debug builds.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: d4d4d6dc013ee322282de7ec0effa54c8827a775
Add support for user stylesheets, and provide one to tests with an `@font-face` rule for it.
Fix#6195.
Many previously-failing tests now pass, and a few previously-passing now fail.
Among the latter, `font-family-013.htm` and `fonts-013.htm` are testing that the Ahem font is not used for characters it doesn’t have a glyph for. They were passing because Ahem was not available at all, and now fail because we don’t implement font fallback correctly.
The others also use Ahem, but I don’t understand yet what’s going on exactly.
Source-Repo: https://github.com/servo/servo
Source-Revision: 08987e3eda370e3eb00876c7f5efdebf3ba0265a
Fix for #6787. I left the commits split up for ease of review, happy to squash when this gets accepted.
Source-Repo: https://github.com/servo/servo
Source-Revision: 172f046688c600c9f51f8db0380e399f6372fe4d
Tying transitions to the DOM node avoids quadratic complexity when
updating them.
Finishing transitions instantly when styles are updated makes our
behavior more correct.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: ffe4bd25a495efd672986f090150b165811b6708
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
This is used for two memory reporting improvements.
- It's used to distinguish "explicit" memory reports from others. This
mirrors the same categorization that is used in Firefox, and gives a single
tree that's the best place to look. It replaces the "pages" tree which
was always intended to be a temporary stand-in for "explicit".
- It's used to computed "heap-unclassified" values for both the jemalloc
and system heaps, both of which are placed into the "explicit" tree.
Example output:
```
| 114.99 MiB -- explicit
| 52.34 MiB -- jemalloc-heap-unclassified
| 46.14 MiB -- system-heap-unclassified
| 14.95 MiB -- url(file:///home/njn/moz/servo2/../servo-static-suite/wikipe
dia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyc
lopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.49 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
| 1.36 MiB -- layout-worker-3-local-context
| 1.34 MiB -- layout-worker-0-local-context
| 1.24 MiB -- layout-worker-1-local-context
| 1.24 MiB -- layout-worker-4-local-context
| 1.16 MiB -- layout-worker-2-local-context
| 0.89 MiB -- layout-worker-5-local-context
| 0.38 MiB -- layout-task
| 0.31 MiB -- display-list
| 0.07 MiB -- local-context
| 1.56 MiB -- compositor-task
| 0.78 MiB -- surface-map
| 0.78 MiB -- layer-tree
```
The heap-unclassified values dominate the "explicit" tree because reporter
coverage is still quite poor.
Source-Repo: https://github.com/servo/servo
Source-Revision: bff5e325a89ab6621a049ac55c1da66e901c776c
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
This isn't done, but contains a working implementation of at least `clientTop`. Feedback would be much appreciated: it's probably far from ideal.
Implementing `clientLeft` is straight-forward, I think, but `clientWidth` and `clientHeight` require accessing the `border_box` - and I don't know how that works, yet.
Source-Repo: https://github.com/servo/servo
Source-Revision: e0bd80f80715bdbdf30de1de9c79a99a41cfd99e
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
