Port to upstream Glutin

[kvark]

Fixes #2356
cc @tomaka

---

This change is 

[kvark]

The code is ready now, although I'm concerned about the input lag. When I just start, say the animation example (cd webrender && cargo run --example animation) it appears to only respond to keys in a few seconds after start, and even then the lag is noticeable. The old code of both wrench and example boilerplate used wait_events, and now I'm changing it to run_forever. Any ideas @tomaka?

[tomaka]

Is it on X11? The X11 code has changed considerably recently, so it's not impossible that a bug sneaked in.

[kvark]

@tomaka yes, I'm on X11

[kvark]

Ugh, another problem: https://tools.taskcluster.net/groups/HBUSRLrbSAqmv8kJJnjljg/tasks/HBUSRLrbSAqmv8kJJnjljg/runs/0/logs/public%2Flogs%2Flive.log#L1254

../target/release/build/osmesa-src-31be08b90e5b125b/out/lib/gallium
thread 'main' panicked at 'No backend is available', /home/worker/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/linux/mod.rs:346:8

[kvark]

cc @staktrace ^
For some reason, the upstream glutin doesn't like running headless on TaskCluster CI. It does work locally on Linux for me though

[staktrace]

I don't know offhand what the problem here is. It looks like the panic is because winit cannot initialize either wayland or X, but if we're running headless I would have thought we wouldn't need either of those?

[kvark]

I guess one way to proceed would be to avoid creating EventsLoop on headless

[staktrace]

Also just a note - since you're modifying .travis.yml you should make the same change to .taskcluster.yml or the two CIs will get out of sync.

[kvark]

@staktrace thanks for the heads up! should be good now.
I think we should have a Makefile to have those basic commands called from either of the CI configs.

[staktrace]

Yeah I think servo has a etc/ci/ folder with automation scripts, something similar would be good to do here

[kvark]

@glennw this should be ready for review (assuming CI passes). Would be great if you could pull this change on your end and see if everything (namely, examples and wrench) still works as expected.

[glennw]

@kvark Sure, I'll do some testing and review it today.

[glennw]

Reviewed 9 of 11 files at r1, 5 of 7 files at r2, 2 of 2 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

webrender/Cargo.toml, line 46 at r4 (raw file):

env_logger = "0.5"
rand = "0.3"                # for the benchmarks
glutin = "0.12"    		 	# for the example apps

nit: tabs here instead of spaces

---

Comments from Reviewable

[glennw]

The tiniest of nits only - still building locally to actually test though.

[glennw]

OK, I tested this a bit - using Wayland on Ubuntu 17.10.

The window decorations are a bit strange (very different to a normal window), and there is no title. Resizing also doesn't work correctly (but I think that was the case previously too, just that you now see uninitialized GPU memory :) ).

I'm fine with landing it like that - I think it's a net win, and it doesn't affect the main functionality.

So, r=me when you're ready to merge this.

[bors-servo]

☔ The latest upstream changes (presumably #2382) made this pull request unmergeable. Please resolve the merge conflicts.

[glennw]

@bors-servo r+

[bors-servo]

📌 Commit 884b5e9 has been approved by glennw

[bors-servo]

⌛ Testing commit 884b5e9 with merge a492386...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster, status-travis
Approved by: glennw
Pushing a492386 to master...

[atouchet]

Could we get a Servo WR update with this to address servo/servo#19901?

[kvark]

@atouchet If you are talking about updating WR version used in Servo, than it wouldn't help. This PR only ports the examples and wrench, which have nothing to do with Servo.

[atouchet]

Alright, I was under the impression that a WebRender update caused the breakage but I guess that is not actually the case then.