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
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
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
