This is a minor refactoring of the touch tracking in compositor, to simplify the code and prepare for more gesture handling (like pinch to zoom). r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 97791dd317893c3b1c203c5d248846ff4fd9daba
…s to a new one for the first time. Resolves#7865.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4067960ba5d309ec6c4c6aef6e7aa231aca0e5d5
I'm just going to keep throwing stuff at try, because running directly on the builders isn't yielding results.
Source-Repo: https://github.com/servo/servo
Source-Revision: c78da15abbffd223290300b6b985d65cd6f03d08
When a layer containing an iframe changes, we also need to resize the
root layer of the subpage. This ensures that content from the child
layer tree is masked to the new size.
Fixes#8301.
Source-Repo: https://github.com/servo/servo
Source-Revision: dc159d055c5e4931648a7046492ec5c63ab922aa
Instead of just converting the mouse into a single "touch" input, Servo can now listen for multi-touch events from Glutin, maintain a list of active touch points, and dispatch events for all of them.
r? @glennw (for the compositor changes) and @jdm (for the DOM changes)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3fdaa6e3f32f6996c416e75119177b98d404adb2
This implements just enough of [Touch Events](http://w3c.github.io/touch-events/) to enable scrolling on Android without regressing basic single-touch interaction like clicking on links.
Dragging a page will scroll it, unless the page calls `preventDefault` on the "touchstart" event.
Does **not** yet support pinch zooming or other multi-touch gestures or events.
Includes a `-Z convert-mouse-to-touch` command line flag for testing on non-touch platforms. This is also enabled by default on Android because Glutin currently translates touch input to mouse events on Android.
Source-Repo: https://github.com/servo/servo
Source-Revision: dcd207f9bf15c9ecf5d043385ba93277e69201f6
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 allows me to do stuff like this.
Those are two compositors rendered on the same OpenGL context, I need this so I can split windows and render them without getting mad with textures and framebuffers, it will also allow me to render the proper parts of the chrome as different web pages without involving dozens of framebuffers and textures.
If I recall correctly I did talk to @glennw about this on IRC some time ago.
This pull request requires https://github.com/servo/gleam/pull/39 to be merged first tho.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8db8a86ab1e943b5102a05d6d31800579fdb7875
Unify all compositor shutdown code paths into two methods, one which
starts the shutdown and the other that finishes it. This simplifies the
way the compositor shuts down and prevents "leaking" pixmaps when
exiting in uncommon ways.
Source-Repo: https://github.com/servo/servo
Source-Revision: 26dd1233103eb75c2e94fcc2ba34c18fa4432afc
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
The structure of this function was confusing, so move some parts out into the
caller where they seem like a more natural fit and add documentation of the
functions
Source-Repo: https://github.com/servo/servo
Source-Revision: e7f73fdfd822fc2f0d3c239a428c739232bdfd12
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
Changed to_string calls to to_owned calls
where was a need.
Source-Repo: https://github.com/servo/servo
Source-Revision: d588ce8d8503bf0b340abfb13e2bd6a228cab900
Currently these both clamp to 100% in one direction and are unbounded in the other direction. This sets default zoom constraints of 10% to 800%. r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: eae3eaf97474febb2c50a7a4d392594cbc8d2da2
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
Before on at least Linux the following failure is hard to root cause:
[~/servo] ./target/debug/servo -o tmp.png ./tests/html/lipsum.html
thread '<main>' panicked at 'assertion failed: res.is_ok()', .../compositor.rs:1508
thread '<main>' panicked at 'You should have disposed of the
pixmap...', .../rust-layers/.../surface.rs:166
Now:
[~/servo] ./target/debug/servo -o tmp.png ./tests/html/lipsum.html
thread '<main>' panicked at 'Error writing png: Permission
denied (os error 13)', .../compositor.rs:1508
thread '<main>' panicked at 'You should have disposed of the pixmap
properly with destroy()! This pixmap will leak!', .../rust-layers/.../surface.rs:166
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: eb556c1ce6ed52e2a71743a088860ac0e0df3e89
and `for foo in bar.iter_mut(), and for foo in bar.into_iter()
(continuation of #7197)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0d6d6a05009606dfbbfc9765d7dc2c745c18f6a5
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
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
… as it isn't painted after first layout comes in.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 1fc50c6ccf98f3df3f47f5910a456a1fb88b73db
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
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
Otherwise, we have to wait for the next vsync. This was capping the
framerate of the particles demo at 30 FPS in most cases.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 416931f4be43826d3b2a96905c22f626c88b603c
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: f778e0eecf7cd8a2b870d18c3c305ff10d6b1894
We currently store LayerBuffers, because previously NativeSurfaces did
not record their own size. Now we can store NativeSurfaces directly,
which saves a bit of space in the surface cache and allows us to create
LayerBuffers only in the PaintTask.
This also means that instead of sending cached LayerBuffers, the
compositor can just send cached NativeSurfaces to the PaintTask.
Source-Repo: https://github.com/servo/servo
Source-Revision: 590cb33bb7ae9f4713a7c2ee8bfe1076c180e392
Currently only the BufferMap is recorded, but a later change will also
measure the memory usage of the compositor tree.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3f69eadc0d55b2f065d59dae84baeac45a0bdc8e
Also updates glutin with a crash fix that was exposed by this patch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ac80bff8e25be65e96daaf6b7403b11d23d561a
This will make it easier to adapt to IPC.
The trickiest part here was to make script tasks spawn new layout tasks
directly instead of having the pipeline do it for them. The latter
approach will not work in multiprocess mode, because layout and script
must run in the same address space and the pipeline cannot inject tasks
into another process.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: e06eaa0064f49bc215e3851f0a3686e1191b356a
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
