It could be used to have mutable JSVal fields without GC barriers.
With the removal of that trait, MutHeap and MutNullableHeap can respectively
be replaced by MutJS and MutNullableJS.
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
FBO status is supposed to depend on the size of the attachments all
matching, so we need to re-check when it changes. We don't ensure
matching yet, but this will prevent regressions when we do.
If we're going to return from this function without updating the
underlying GL state because of a WebGLError, we shouldn't have updated
our shadow of the GL state.
When the FBO has been unbound, anything that happened to its
attachments (deletion, new binding, reallocation) may have caused it
to change status.
This doesn't change any test results currently, because we're not
checking if the attachments are deleted, the wrong size, or have
appropriate formats.
This is part of general GL behavior: when an object is deleted, look
through the currently bound objects and detach the deleted object from
them. Detaching an object from an FBO causes it to need to be
re-checked for its status.
Implement IsBuffer, IsFramebuffer and IsRenderbuffer for WebGLRenderingContext
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy --faster` does not report any errors
- [X] These changes fix#11357
- [X] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11426)
<!-- Reviewable:end -->
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.
