Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
In order to support multiple API's (WebVR + WebXR) being enabled simultaneously, a new class, gfx::VRManagerEventObserver, implements a pure virtual interface to be shared by both the WebVR and WebXR observers of XR device related events.
Differential Revision: https://phabricator.services.mozilla.com/D39985
--HG--
extra : moz-landing-system : lando
Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
have texture cache to manage potentially multiple array textures of each type.
Differential Revision: https://phabricator.services.mozilla.com/D39912
--HG--
extra : moz-landing-system : lando
We already skip painting hit test items. We can do even better
by not including them in the recording at all.
Differential Revision: https://phabricator.services.mozilla.com/D40859
--HG--
extra : moz-landing-system : lando
There's another call inside Render() but that's usually too late.
Depends on D40558
Differential Revision: https://phabricator.services.mozilla.com/D40559
--HG--
extra : moz-landing-system : lando
An alternative approach, which I would have preferred, would be to keep the old
mClonedLayerTreeProperties around, so that future frames can compare to the
last non-aborted mClonedLayerTreeProperties. However, that doesn't work in the
current world because mClonedLayerTreeProperties->ComputeDifferences has side-
effects.
Differential Revision: https://phabricator.services.mozilla.com/D40558
--HG--
extra : moz-landing-system : lando
This makes it clear that these belong to a single frame and makes some assumptions explicit.
For example, in the old code, mDocFrameCounts.size() was the same as mPendingFrames.size()
when a pending frame was added, but then the sizes differed during rendering because a frame's
mDocFrameCount would be popped at the beginning of rendering while mPendingFrames would be
popped at the end of rendering.
This modification also makes some clearing of values unnecessary. A new frame always starts out
with cleared values for mDocFramesSeen and mFrameNeedsRender.
This patch also combines the two locks in HandleFrameOneDoc.
Depends on D40373
Differential Revision: https://phabricator.services.mozilla.com/D40374
--HG--
extra : moz-landing-system : lando
The only place that increments mRenderingCount, HandleFrameOneDoc, also synchronously calls FrameRenderingComplete
at the end of the function, which decrements mRenderingCount again. So it can never grow beyond 1.
Depends on D40372
Differential Revision: https://phabricator.services.mozilla.com/D40373
--HG--
extra : moz-landing-system : lando
IncRenderingFrame only had one caller. Inlining it into HandleFrame makes it clearer
how the values in mWindowInfos are mutated and in what order calls happen.
This also renames HandleFrame to HandleFrameOneDoc, because we're expecting one call
per document before we actually trigger the render.
Depends on D40370
Differential Revision: https://phabricator.services.mozilla.com/D40371
--HG--
extra : moz-landing-system : lando
When PersistentBufferProviderShared::ClearCachedResources() is called, PersistentBufferProviderShared keeps front TextureClient. But TextureHost's read lock might be released by host side. Then TextureClient's read lock could not be used for checking if the TexutreClient is used by host side.
Differential Revision: https://phabricator.services.mozilla.com/D40440
--HG--
extra : moz-landing-system : lando
This change creates the new export CreateVRWindow from vrhost.dll. This API
results in spawning a new Firefox window with the Firefox Reality 2D UI and
returns data needed for the host to interact with it. VRShMem is used to pass
data across process boundaries during this bootstrap process.
Additional tests are added to vrhost to be later converted to unittests.
Differential Revision: https://phabricator.services.mozilla.com/D40236
--HG--
rename : gfx/vr/vrhost/vrhost.cpp => gfx/vr/vrhost/vrhosttest.cpp
extra : moz-landing-system : lando
In order to support the WebXR implementation, VRDisplayState is being extended to enumerate the type of sessions a device supports (Inline, Immersive-VR, or Immersive-AR) and to report if the blend mode for AR would be additive or alpha blended).
Differential Revision: https://phabricator.services.mozilla.com/D39916
--HG--
extra : moz-landing-system : lando
those unwrap_or are mostly seen during the batching, where we should asssume that
the primitives are not clipped out and just unwrap() accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39940
--HG--
extra : moz-landing-system : lando
Refactors get_clip_result_complex to cover ClipOut cases for rectangles as well
as Clip for non-repeated images.
Differential Revision: https://phabricator.services.mozilla.com/D40094
--HG--
extra : moz-landing-system : lando
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
--HG--
extra : moz-landing-system : lando
Now that there is only ever a single handle to the `CompositionRecorder`, it no
longer needs to be ref-counted. And since the `WebRenderCompositionRecorder` is
owned exclusively by the `RenderThread`, it no longer needs a mutex. All the
code that resulted from having handles to the `WebRenderCompositionRecorder` on
two different threads is now no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39791
--HG--
extra : moz-landing-system : lando
Since we are not writing frames to disk from the `CompositorBridgeParent` in
the WebRender case, we do not actually need a handle to the
`(WebRender)CompositionRecorder` there. Instead, the `HostLayerManager` and
`RenderThread` can maintain exclusive handles to these objects. This will allow
us to use unique pointers for these objects and delete code in a follow up
patch.
Differential Revision: https://phabricator.services.mozilla.com/D39790
--HG--
extra : moz-landing-system : lando
On macOS, if we try to write the collected frames from the
`CompositorBridgeParent` we will not have an active GL context, resulting in a
crash. Writing the frames from the `RenderThread` solves this problem.
Differential Revision: https://phabricator.services.mozilla.com/D39789
--HG--
extra : moz-landing-system : lando
Instead of blindly attempting to write frames to disk, we now ensure that the
`CompositionRecorder` exists. In the case where we have not allocated one,
calling `windowUtils.setCompositionRecording(false)` will instead print an
error message to the browser console.
In addition, attempting to call `windowUtils.setCompositionRecording(true)`
while a `CompositionRecorder` exists will also result in an error message.
Differential Revision: https://phabricator.services.mozilla.com/D39584
--HG--
extra : moz-landing-system : lando
