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
Issue: #3144
We created a sniffer task in components/net/, added a call in resource_task load function to create a new sniffer task (sending all the data), and sniffer_task currently sends all the data back to resource_task.
The purpose of this request is to get feedback from @jdm on our progress before moving forward and writing tests.
first-class.
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.
Because of #2122 I cannot write test for this right now because it will be failing randomly due to that iframe issue. However, if it doesn't fail due to that issue a test like this:
```html
<html>
<head>
<meta charset="utf8" />
<script src="harness.js"></script>
<title>Iframe contentDocument test.</title>
</head>
<body>
<iframe src="test_iframe_contentDocument_inner.html" id="iframe"></iframe>
<script>
waitForExplicitFinish();
var timeout = 100;
var iframe = document.getElementById('iframe');
function test_contentWindow() {
if (!iframe.contentWindow) {
// Iframe not loaded yet, try again.
// No load event for iframe, insert bug number here.
setTimeout(test_contentWindow, timeout);
return;
}
is(iframe.contentDocument.getElementById('test').textContent, 'value');
finish();
}
test_contentWindow();
</script>
</body>
</html>
```
where inner is simply:
```html
<html><body><div id="test">value</div></body></html>
```
passes.
I have added `SameOrigin` method to the `UrlHelper`. I wanted to reuse it in [`constellation.rs` same_script check](f0184a2d01/components/compositing/constellation.rs (L625)) but I it didn't want to compile saying
```
error: unresolved import `dom::urlhelper::UrlHelper`. Maybe a missing `extern crate dom`?
```
So I didn't include it in this PR for now.
There is more discussion about the cross origin iframes in [another issue](https://github.com/servo/servo/issues/3939). In this PR I just added same origin check.
Accepted and closed incoming streams
Added header to for constant use.
Removed extra spaces.
Corrected spacing to conform to coding standards.
Corrected spacing to conform to coding standards.
Corrected spacing to conform with coding standards.
Moving new import next to old import for devtools_traits as specified in comment.
Removed method definition to include as inline code and changed to iter_mut.
Using loops to exit devtools on server exit message and disconnected message to simply break as suggested in the comment.
Removing TODO comment for completed functionality.
Moved the operation for exit of devtools on servo closing outside the match loop.
Removing trailing ';' and adding new line before connection closing loop.
Instead of creating a display list for the entire page, only create one
for an area that expands around the viewport. On my machine this makes
incremental layout of http://timecube.com 50% faster.
I was messing around devtools code and saw some TODOs, is anyone working on it? I took one of them:
```// TODO: this really belongs in the protocol module.```
I would be glad to help with this if no one is on it already, just let me know.
This is the first step to allowing incremental iframe creation and destruction. This should eliminate task failures when an iframe is added to the frame tree lazily via script.
