Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
GVST is how these probes sent data in Fenix and is now unnecessary (and doesn't send data in Fenix release) since Firefox Desktop has direct access to Glean. We therefore need to clean them up in some capacity.
Following the recommendations from the GeckoView Streaming (GVST) validation effort, this is a pure Glean api implementation of the metrics that fell under gfx and its subcategories in geckoview streaming.
Each metric retains its previous name, and gains a Glean Interface for FireFox Telemetry (GIFFT) version, such that downstream data analyses will not be impacted.
Differential Revision: https://phabricator.services.mozilla.com/D198872
If GL is not thread-safe, then the check for whether we use the canvas render thread
is not accurate. The thread-safe check takes precedence, and if we are not thread-safe,
we are actually on the render thread. It should be safe to not force sync here since
we aren't actually on the compositor thread at all.
Differential Revision: https://phabricator.services.mozilla.com/D196864
The one reason a surface can be in the SharedSurfacesParent table and not registerd is
because it was registered during shutdown. In this case, we shouldn't be asserting anyway
if something just tries to unregister it thereafter.
Differential Revision: https://phabricator.services.mozilla.com/D196139
In an effort to understand if data collected via the Geckoview Streaming
API differs materially from that collected in Glean, we will implement
some temporary data collections that cover the existing use cases of the
former.
Differential Revision: https://phabricator.services.mozilla.com/D191119
In current m-c, async RemoteTexture wait at RenderThread stops window update when the wait is too long. If async RemoteTexture is handled by WebRenderAPI, window could be updated during long async RemoteTexture wait.
async RemoteTexture wait of root WebRenderBridgeParent are disabled to simplify WebRenderAPI's wait handling.
offscreen canvas case is handled by WebRenderImageHost by Bug 1827578.
Differential Revision: https://phabricator.services.mozilla.com/D175590
It should be OK to wait remote texture ready of offscreen canvas at WebRenderImageHost. Offscreen canvas uses ImageBridge. And ImageBridge works asynchronously.
WebRenderImageHost::UseRemoteTexture() is split to WebRenderImageHost::PushPendingRemoteTexture() and WebRenderImageHost::UseRemoteTexture(). It is for handling RemoteTexture ready callback in WebRenderImageHost.
Differential Revision: https://phabricator.services.mozilla.com/D175226
RenderThread::PushPendingRemoteTexture() notifies pending RemoteTextures to RenderThread. And RemoteTextureMap::CheckRemoteTextureReady() is used for checking if a RemoteTexture is ready. If the RemoteTexture is not ready during the function call, callback will be called when the RemoteTexture becomes ready.
RemoteTextureMap::GetExternalImageIdOfRemoteTextureSync() is changed to RemoteTextureMap::GetExternalImageIdOfRemoteTexture() and wait of RemoteTexture ready in the function is removed. The wait of RemoteTexture ready is done by the callback of the CheckRemoteTextureReady().
Differential Revision: https://phabricator.services.mozilla.com/D174732
Refactor RenderThread's RenderNotifier event handling for Bug 1804233.
Bug 1804233 is going to add deferring processing of RenderNotifier events if RemoteTexture is not ready. For handling it, RenderNotifier events are processed by using WrNotifierEvent queue.
Differential Revision: https://phabricator.services.mozilla.com/D174524
It is a preparation for Bug 1804233. From bug 1776885 comment 6, we need to defer WebRender rendering on render thread if remote texture is not ready. To do it, ResultMsg messages handling needs to be controlled.
By adding the followings, ResultMsg messages handling could be controlled by RenderThread.
- FramePublishId to new_frame_ready()
- Renderer::set_target_frame_publish_id()
new_frame_ready() has frame_publish_id. The publish_id could be set to Renderer::set_target_frame_publish_id(). Then Renderer::update() defers processing of ResultMsg, if frame_publish_id of ResultMsg::PublishDocument exceeds target_frame_publish_id.
Differential Revision: https://phabricator.services.mozilla.com/D173512
Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().
Differential Revision: https://phabricator.services.mozilla.com/D169796
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
