This implements the `canvas`, `drawingBufferHeight` and
`drawingBufferWidth` getters to `WebGLRenderingContext`, and an initial
version of `getParameter`.
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)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6183)
<!-- Reviewable:end -->
Example output from the memory profiler:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
The buffer maps aren't huge, but they're worth measuring, and it's good
to get the memory profiler plumbing into PaintTask.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6199)
<!-- Reviewable:end -->
* Add parser support for 3d transforms.
* Change ComputedMatrix to a representation that suits interpolation.
* Switch stacking contexts to use 4x4 matrices.
The transforms themselves are still converted to 2d and handled by azure for now, but this is a small standalone part that can be landed now to make it easier to review.
This puts the larger sub-trees first. E.g. this:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task
| 0.78 MiB -- buffer-map
```
becomes this:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.78 MiB -- paint-task
| 0.78 MiB -- buffer-map
| 0.26 MiB -- display-list
```
This matches how Firefox's about:memory works.
Now that this is done for all sub-trees, the ad hoc sorting done for
Linux segments is no longer necessary, and has been removed.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6200)
<!-- Reviewable:end -->
This puts the larger sub-trees first. E.g. this:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
becomes this:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
| 0.26 MiB -- display-list
```
This matches how Firefox's about:memory works.
Now that this is done for all sub-trees, the ad hoc sorting done for
Linux segments is no longer necessary, and has been removed.
Example output from the memory profiler:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
The buffer maps aren't huge, but they're worth measuring, and it's good
to get the memory profiler plumbing into PaintTask.
