ecoal95 9dbd03da1c servo: Merge #6083 - First steps to layerize canvas (from emilio:layerize-canvas); r=pcwalton ... 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 --HG-- rename : servo/components/gfx/color.rs => servo/components/gfx_traits/color.rs		2015-05-20 15:42:06 -05:00
..
Cargo.toml	servo: Merge #6083 - First steps to layerize canvas (from emilio:layerize-canvas); r=pcwalton	2015-05-20 15:42:06 -05:00
color.rs	servo: Merge #6083 - First steps to layerize canvas (from emilio:layerize-canvas); r=pcwalton	2015-05-20 15:42:06 -05:00
lib.rs	servo: Merge #6083 - First steps to layerize canvas (from emilio:layerize-canvas); r=pcwalton	2015-05-20 15:42:06 -05:00