Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
switch to using webrender_traits::ImageData
update use of webrender_traits::StackingContext in layout
use webrender_traits::channel::msg_channel in webgl ipc
fix use of resource_override_path in components/servo/lib
This is not a complete implementation yet: It doesn't clear the
contents of the renderbuffer on creation. However, Gecko's plan to
only clear renderbuffers when the first FBO using them is the
simplest.
This allows to cleanup resources earlier if they stop being used. Right
now all resources were cleaned up when the context was destroyed, this is
a slightly better approach.
We ignore the possible failure of the send() call, since we don't keep
track of these resources from the `WebGLRenderingContext` structure, so
a texture could be destroyed after the context and give us problems.
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.
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 want to keep track of them from the context).
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.
