This involved some refactoring of the 2d context code, which lead to some more test passed there.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0f8c1b460100f226df954a3924598434f3dda9b2
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
Prior to #7416 and #7401, many of these `impl` sections were not
identical
Source-Repo: https://github.com/servo/servo
Source-Revision: 2f227a034a12158e2592b645c061d92c87c8eba6
Now that `JSRef<T>` is gone, there is no need to have helper traits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 909429702972d53bf02dfe9a4aa93ea0cb588cf4
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
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
This necessitated getting rid of the boxed trait object that was being
be passed between the script task and the image cache task.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e13ebf712de444132a6cc90f394c121d8d751c4c
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
fixes#6524. I had to make an additional change not mentioned in the ticket - adding the `#[feature]` to enable deriving custom traits but I assume that's expected at this time.
Source-Repo: https://github.com/servo/servo
Source-Revision: bbb39082e0f640400546d2084a450a8675820a82
I left out checking invalid values when setting the shadows attributes.
r? @nox @pcwalton
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 02303941bef5f5bbdbec750ab0dfa0b77f32345a
> Here it is.
>
> ~~There's two major things that are unfinished here:~~
> - ~~Dealing with the unroot_must_root lint. I'm not sure about the value of this lint with the new rooting API.~~ Done.
> - ~~Updating the Cargo.locks to point to the new SM and SM binding.~~ Done.
>
> I also included my fixes for the rust update, but these will disappear in a rebase. A rust update is necessary to support calling `Drop` on `Heap<T>` correctly when `Heap<T>` is inside a `Rc<T>`. Otherwise `&self` points to the wrong location.
>
> Incremental GC is disabled here. I'm not sure how to deal with the incremental barriers so that's left for later.
>
> Generational GC works. SM doesn't work without it.
>
> The biggest change here is to the rooting API. `Root` was made movable, and `Temporary` and `JSRef` was removed. Movable `Root`s means there's no need for `Temporary`, and `JSRef`s aren't needed generally since it can be assumed that being able to obtain a reference to a dom object means it's already rooted. References have their lifetime bound to the Roots that provided them. DOM objects that haven't passed through `reflect_dom_object` don't need to be rooted, and DOM objects that have passed through `reflect_dom_object` can't be obtained without being rooted through `native_from_reflector_jsmanaged` or `JS::<T>::root()`.
>
> Support for `Heap<T>` ended up messier than I expected. It's split into two commits, but only because it's a bit difficult to fold them together. Supporting `Heap<T>` properly requires that that `Heap::<T>::set()` be called on something that won't move. I removed the Copy and Clone trait from `Heap<T>` so `Cell` can't hold `Heap<T>` - only `UnsafeCell` can hold it.
>
> `CallbackObject` is a bit tricky - I moved all callbacks into `Rc<T>` in order to make sure that the pointer inside to a `*mut JSObject` doesn't move. This is necessary for supporting `Heap<T>`.
>
> `RootedCollectionSet` is very general purpose now. Anything with `JSTraceable` can be rooted by `RootedCollectionSet`/`RootedTraceable`. Right now, `RootedTraceable` is only used to hold down dom objects before they're fully attached to their reflector. I had to make a custom mechanism to dispatch the trace call - couldn't figure out how to get trait objects working for this case.
>
> This has been tested with the following zeal settings:
>
> GC after every allocation
> JS_GC_ZEAL=2,1
>
> GC after every 100 allocations (important for catching use-after-free bugs)
> JS_GC_ZEAL=2,100
>
> Verify pre barriers
> JS_GC_ZEAL=4,1
>
> Verify post barriers
> JS_GC_ZEAL=11,1
Source-Repo: https://github.com/servo/servo
Source-Revision: e7808c526c348fea5e3b48af70b7f1a066652097
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
The fillStyle and strokeStyle attributes can be either strings(color), CanvasGradients, or CanvasPatterns.
The current implementation only considers strings(color).
r? @nox @jdm @pcwalton
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: ce30807be594d62b75772eac6356f84089a18c09
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
--HG--
rename : servo/components/gfx/color.rs => servo/components/gfx_traits/color.rs
With this patch, it is now possible to create nice animations using the canvas.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5f2a8494be44d57b74bda24f2fa6b6976f71531b
* Simpler image cache API for clients to use.
* Significantly fewer threads.
* One thread for image cache task (multiplexes commands, decoder threads and async resource requests).
* 4 threads for decoder worker tasks.
* Removed ReflowEvent hacks in script and layout tasks.
* Image elements pass a Trusted<T> to image cache, which is used to dirty nodes via script task. Previous use of Untrusted addresses was unsafe.
* Image requests such as background-image on layout / paint threads trigger repaint only rather than full reflow.
* Add reflow batching for when multiple images load quickly.
* Reduces the number of paints loading wikipedia from ~95 to ~35.
* Reasonably simple to add proper prefetch support in a follow up PR.
* Async loaded images always construct Image fragments now, instead of generic.
* Image fragments support the image not being present.
* Simpler implementation of synchronous image loading for reftests.
* Removed image holder.
* image.onload support.
* image NaturalWidth and NaturalHeight support.
* Updated WPT expectations.
Source-Repo: https://github.com/servo/servo
Source-Revision: ac0645c2363b5a6ea3930b0857b3a27f1b6d033f
@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
