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
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
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
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
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
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
…s for frame treese in script tasks.
This underreports by a significant amount, since only Document, Window and CharacterData (ie. text) nodes are fully represented. That being said, every HTML element in the tree is measured, but only counted as a Node. It's easy to improve this, it just requires adding the appropriate HeapSizeOf derives and increasing the granularity of `measure_memory_for_eventtarget`. google.com shows a dom-tree value of 0.24 MB for me at the moment.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: 84e25befdd97cf74fb00707dbe150d59d980e977
Credits for Mike Blumenkrantz (@zmike), I just rebased against trunk and
fixed the url serialization.
Fixes#6178.
Source-Repo: https://github.com/servo/servo
Source-Revision: 82e476fd07564f2822a5af1f397751027ddf7258
The main work is in the the rust-clipboard library, this PR updates Cargo.lock and adds plumbing.
0337e48b3f
Source-Repo: https://github.com/servo/servo
Source-Revision: 28e163d6c44f1d85fbaea7f236da40972b6a63b1
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
This checks every .toml file for an asterisk and prints an error if found.
Source-Repo: https://github.com/servo/servo
Source-Revision: 58e9bc6583b6ebbeb27e3b28a6b271ee48cd695a
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: ef9715203edf0a280d019b6e8823666f0e7020be
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
Source-Repo: https://github.com/servo/servo
Source-Revision: 10b0d8c537c226400a617d28e8a060f9ca53d242
The compositing context, painting context and display metadata have all
been collapsed into a single NativeDisplay class.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4674afe846df6720882da28cbd2c3087c17d0b22
Supersedes #6488. Changes since then:
* Fix a few places where we needed cfg(feature = "window") in order to compile without the feature.
* Zoom-in shortcut now works both with and without shift. (Uses a guard because I couldn't think of another way to do it without CTFE.)
* Back/forward shortcuts now correctly use Alt on non-Mac platforms.
* The back/forward shortcuts that use square brackets are now non-Windows, rather than Mac-only. This roughly matches XP_UNIX: http://hg.mozilla.org/mozilla-central/file/d4c4ce7f060c/browser/base/content/browser-sets.inc#l354
Source-Repo: https://github.com/servo/servo
Source-Revision: 420cf4c8dcbe4bba822bb6980b301416d9b5526e
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
Overlaps a bunch with #6288. Putting this here so @frewsxcv can take a look and we can figure out how to merge our work together.
Source-Repo: https://github.com/servo/servo
Source-Revision: 96311aa9b71abb31fd8e4283de9e1b58813108a3
Getting these down to the embedding API level required that I redo the bindings generator again, so this is more commits than anticipated.
@mbrubeck @Manishearth @pcwalton but NOT @larsbergstrom so don't even look at this.
Source-Repo: https://github.com/servo/servo
Source-Revision: b0f3417cffb211d547853b8069e7a444a1d9964f
This fixes various race conditions that affect test execution when using the servodriver product. It doesn't yet do enough to make servodriver a viable alternative to the normal servo test executor.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0b7886b15fa986612e81e7da3dd88b2d7949e719
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
This moves webdriver_traits into msg to avoid a circular dependency.
Source-Repo: https://github.com/servo/servo
Source-Revision: d08995e1a94fa093b7fc1e5d918d9dca79f260d6
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
This fixes a hang found while testing the jQuery test suite.
Source-Repo: https://github.com/servo/servo
Source-Revision: c51e9f04559f04f1e820b792261e1653c6869ee5
This improves Servo's performance on large pages.
Please double-check the logic when it comes to nested layers—I'm sure I've messed up some of the geometry calculations :)
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 0880e54f987bac7c34c934ef6ee36f46475b06e3
This allows most of the jquery test suite to run without exhausting thread resources.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7e022b25a8ab87897180dcf1b6aff8d9b57adcb4
The basic idea is it's safe to output an image for reftest by testing:
- That the compositor doesn't have any animations active.
- That the compositor is not waiting on any outstanding paint messages to arrive.
- That the script tasks are "idle" and therefore won't cause reflow.
- This currently means page loaded, onload fired, reftest-wait not active, first reflow triggered.
- It could easily be expanded to handle pending timers etc.
- That the "epoch" that the layout tasks have last laid out after script went idle, is reflected by the compositor in all visible layers for that pipeline.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5e61ebaa05e5babb7b2fdd1347b6cdd23df38e62
