…eeded for the instancing changes in WR - see servo/gleam@fc7e28e).
Hopefully the build machines and everyone using Servo has GL 3.3 available on their machines - if it causes any problems, we can revert this change and investigate further.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6b1a08c051f3be4b7bc7e6200053dfa530ecd106
Was done while implementing sequence arguments.
Depends on #9056.
Source-Repo: https://github.com/servo/servo
Source-Revision: c13e84010d1dd33c5532cdfa2937dddd4db4dd26
Closes#9228
I think this code will actually do what is desired now. I had to rebase off of master since WebGLPaintTask was renamed to WebGLPaintThread in a commit since last night.
I'm sorry this has been so much trouble so far. I'm still learning how things are done around here. I didn't even think about trailing whitespace, but now I know about the test-tidy tool.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6b1e73c1c0cf3fe2c935df0de667145bc6130461
The core feature is marked as stable and gives this nice warning:
```
servo/components/canvas_traits/lib.rs:7:12: 7:16 warning: this feature is stable. attribute no longer needed, #[warn(stable_features)] on by default
/servo/components/canvas_traits/lib.rs:7 #![feature(core)]
```
This commit removes the usage of this feature.
Source-Repo: https://github.com/servo/servo
Source-Revision: 996c0a60b81e7d7e0fbfea81a546771ea9327df6
These two tiny changes were making WebGL textures not work.
It was not seen in our texturing test since it only used one texture,
we render to a texture by default, and that texture was bound to
`gl::TEXTURE_2D`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2cfcc26d9e5cc732a7594f0c0d96d4174c6b0a8a
This makes the initial download for skia go from a 300 MB git repository to a 5 MB tarball. This should help with issues like #6132 and #7687.
Fix https://github.com/servo/skia/issues/70
This builds, but the at the moment causes a number of tidy errors for duplicated crates.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8b95d7b8d860ec4c0834192083361a9fb78ddbeb
Pretty straightforward use of lookup tables to replace a bunch of expensive float operations.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9a34decec295563d3b4050bc53daad142450e0d5
Depends on servo/rust-azure#201 and pcwalton/ipc-channel#10.
Closes#7422.
r? @mbrubeck (don't r+ until the upstream dependencies have landed)
cc @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e2048d57c4c0602c5a6b82db8cb76e6c3e5467fa
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
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
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
Since it probably won't merge until multiprocess lands, I plan to use this PR to keep improving WebGL support until it can land.
Main TODOs are integration of tests, since it seems https://github.com/KhronosGroup/WebGL/issues/1105 is going nowhere, adding missing calls and proper painting via native surfaces instead of readback.
I can't resolve conflicts right now because of time but I will do it soon.
Source-Repo: https://github.com/servo/servo
Source-Revision: a109a333f1f95d4fc677b29e3613b2615514c080
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
The idea here is to land this before making images and canvas IPC-safe,
because this will shake out bugs relating to the shared memory. There
are currently test timeouts that are preventing multiprocess images and
canvas from landing, and I believe those are due to the inefficiency of
sending large amounts of data in the unoptimized builds we test with. By
moving to shared memory, this should drastically reduce the number of
copies and `serde` serialization.
Under the hood, this uses Mach OOL messages on Mac and temporary
memory-mapped files on Linux.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: ed1b6a3513e7546b580693f554a081bc0c7c478a
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 improves the encapsulation and consistency in our WebGL
implementation.
Also allows to implement new methods such as `getShaderSource()`.
It will also allow us to use `delete()` in the destructors of them (note
that we will probably want to keep track of them from the context before).
Some concerns:
**Trait method repetition**:
I'm aware that the traits `WebGL{Buffer,Renderbuffer,Framebuffer,Texture}Helpers` are basically the same, but `delete()` and `id()` methods are everywhere. I've thought something like:
```rust
pub trait WebGLIdentifiable {
type WebGLId; // id is sometimes i32 (see WebGLUniformLocation)
fn id(&self) -> Self::WebGLId;
}
pub trait WebGLBindable {
fn bind(&self);
}
pub trait WebGLDeletable {
fn delete(&self);
}
```
But I'd want to know your opinion first.
**`renderer` repetition**:
Thought of moving the field: `renderer: Sender<CanvasMsg>` to `WebGLObject`, but I think it makes it way more complicated to read, and also a bit unnecessary, at least IMO (`WebGLObject` will never interact with the field directly). It would also mean that all `WebGLObject`s should have one, which is true at this moment, but maybe not with WebGL 2, for example.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0f8095b950dd144497919cfea65a1f154ed3ae9a
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
Depends on servo/rust-azure#170 which has been already merged.
So this patch contains the update of rust-azure.
r? @nox
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: e1b28d893e54601bf497d0d5b83d77658ca16bac
