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
It seems @hyowon uploaded her canvas shadow patch faster than me; I've handled the color dependency a bit different, this way `gfx_traits` is not required by the script module.
Source-Repo: https://github.com/servo/servo
Source-Revision: c8c7bd900dde73d4fddafea8239f44440f1c863b
The first step of the implementation for shadows in canvas.
r? @nox @jdm
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: f163f2bf0d32861ea20470d405bb517ed5b09e84
This commit implements:
* WebGLFramebuffer
* WebGLRenderbuffer
* WebGLTexture
And adds the following methods to `WebGLRenderingContext`:
* create{Texture,Framebuffer,Renderbuffer}
* bind{Texture,Framebuffer,Renderbuffer}
* destroy{Buffer,Texture,Framebuffer,Renderbuffer}
Fixes:
* WebGLUniform location shouldn't inherit from WebGLObject.
Known Issues:
* WebGL objects have to be destroyed on drop, we may want to keep a reference to the context, or maybe a clone of the renderer to achieve this
Also refactors a huge part of the current implementation, to allow
failing on creation of different WebGL objects.
Blocked on https://github.com/servo/gleam/pull/22
A reftest for most of the added functionality is not doable right now,
we need a few more functions in order to upload a texture, for example.
Source-Repo: https://github.com/servo/servo
Source-Revision: e09c555a41b0803388e54013ac8885fb789a0fa6
This implements the `canvas`, `drawingBufferHeight` and `drawingBufferWidth` getters to `WebGLRenderingContext`, and an initial version of `getParameter`.
r? @jdm or @nox?
Source-Repo: https://github.com/servo/servo
Source-Revision: 042737793b1995ad93dc093ea12ec986b99e64b8
r? @jdm
I couldn't add the `getContextAttributes` method since `CodegenRust`
doesn't know how to return a dictionary value, I'll take a look at it ASAP.
I think the helper functions can return directly the renderer, since they're used just for that, but I wanted to hear your opinions about this.
By the way I'm interested in adding more serious tests for WebGL, and I think the [khronos conformance suit](https://github.com/KhronosGroup/WebGL/tree/master/conformance-suites/1.0.3) should be the best option.
Should I try to integrate it in wpt, or making a `tests/webgl` directory (or similar) inside the servo tree? (Maybe this question should be for @Ms2ger)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0de09b936e5e37c15b7865157a98ad78b1077659
This patch turns on antialiasing for the canvas, and updates the painting code to use the updated Azure DrawOptions defined in servo/rust-azure#158.
Source-Repo: https://github.com/servo/servo
Source-Revision: c97c0a9f94208828c617cbd99efd8e3e410c69ee
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
GitHub doesn't allow me to reopen#5769, so I created this.
Sorry about the merge fail, my bad :/
cc/ @jdm @dmarcos
---
This PR uses customized GL context creation code, right now only working under Linux, so I expect the clearcolor test to fail on other platforms.
It addresses some other problems:
* Propagates context creation error to the top, returning null if not found.
* Uses GLContextAttributes, which will allow us to write WebGLContextAttributes easily.
* Doesn't allow a 2d context and a WebGL context coexist.
* Panics when resizing the context to larger dimensions (to be fixed soon, but better than blindly allowing it).
Removes some unused dependencies
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f2ad9376eaf598898387ea2c26f48c3ceb0330d
@jdm @ecoal95 I'm working on making VR happen in the Browser and I want to bring to Servo the [webVR APIs](https://github.com/MozVR/webvr-spec/blob/master/webvr.idl) we already have in Gecko. Before anything happens we need a working implementation of WebGL (and also the [fullscreen API](https://fullscreen.spec.whatwg.org/)). My implementation is very basic and probably naive (I just recently started to contribute to Servo). My patch is just a starting point:
- It only implements ```clearColor``` and ```clear``` methods of the [WebGL spec](https://www.khronos.org/registry/webgl/specs/latest/).
- It uses the readback strategy that ```canvasRenderingContext2D``` is using (The webgl task paints stuff independently on it's own buffer and the compositor task request the pixels back to the webgl task when it needs them) I'm sure there are much better ways to handle this. Latency and FPS are critical in VR so we have to figure out the fastest way to push pixels to the screen. I've read something about layerizing the canvas but I'm still not sure what that even means :)
- There's an included test you can try ```./mach run tests/ref/webgl-context/clearcolor.html```
@ecoal95 I know you'll be working on this for the next three months. With a foundation in place we will be able to make quick progress in parallel. This is exciting!
Source-Repo: https://github.com/servo/servo
Source-Revision: e4b620ea54c94e03095e4108bce94ec750416bba
This patch enables the use of `save()` and `restore()` for the canvas context, which is used by *a lot* of sites and scripts.
Depends on servo/rust-azure#153.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9c7c289acae3ea012338a5b25bc50a10e7f7074d
"Links to the multipage version of the specification are unfortunately
likely to break over time."
-- https://html.spec.whatwg.org/multipage/asefij.html
This commit removes all references to the specific pages when viewing
WHATWG using multipage mode. I went through all these links and they
redirect fine.
Regex used to generate this commit:
`s_whatwg.org/multipage/.*#_whatwg.org/multipage/#_g`
Source-Repo: https://github.com/servo/servo
Source-Revision: d90fe2b0889dee4eb27693aca7670969d5253424
This patch adds support for setting the line cap and join. However, it seems there's a problem on the azure-side, as the line cap setting doesn't work. Changing either the default values or using the new function has no effect. Line join works fine though.
Source-Repo: https://github.com/servo/servo
Source-Revision: fe81ce942a36b08ece8ef6d58de72624a961eeaa
This exposes some other canvas tests which were marked as PASS before. Two strokeRect related tests are fixed by #5612, and lineCap/lineJoin will have an implementation soon.
Source-Repo: https://github.com/servo/servo
Source-Revision: 325899bfad2f87e2c46b96bc542110d8f0cada48
This patch enables the use of `arc()` on the canvas.
I couldn't add reftest this time, as it involves some antialiasing issues, and so the reference doesn't match.
Source-Repo: https://github.com/servo/servo
Source-Revision: e8f1a046c6c704915419cb75181f6e0bc402ef98
This patch enables the use of `lineTo()` on the canvas.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9eaa48b793de78b713e6c3a3c79c4060084d5fbe
