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
This change was unintentional and may be responsible for the performance regression seen in
bug 1570256.
Differential Revision: https://phabricator.services.mozilla.com/D40085
--HG--
extra : moz-landing-system : lando
ScaledFontFreeType::GetWRFontInstanceOptions() was neglecting to set
the FontInstanceFlags::EMBEDDED_BITMAPS flag. This was causing us to
always take the non-bitmap path when rasterizing the glyph, which
fails on android because emoji fonts are bitmap only. Setting this
flag causes glyphs to be rendered correctly on android webrender.
Differential Revision: https://phabricator.services.mozilla.com/D40062
--HG--
extra : moz-landing-system : lando
Allow the swizzle to be configurable with a texture binding. This is still experimental and needs to be tested well on all platforms.
Basic approach is the following:
- WR device figures out how it can use BGRA and makes the texture cache format configurable at run-time. It tries to make the uploads to the shared texture cache pages to be done without any driver conversions, and without extra memory allocated.
- it also reports the preferred input format for the images, which may be different from the texture cache format
- if WR texture cache is asked to allocate a shared texture with a different (swizzled) format from the preferred, it associates the cache entry with a swizzle
- the swizzle becomes a part of the `SourceTexture`, which affects batch splitting
- when a texture reaches binding by GL device, it checks whether the current swizzle on this texture doesn't match the given one, and configures the texture sampling accordingly
- we can't use blits with swizzling, so when that needs to happen we use `cs_copy` path, which is now mostly rewritten
The idea is that Gecko would ask WR for the preferred format and configure its image decoding to produce image data that doesn't require any swizzling.
The PR changes existing texture upload (and batching) paths. On Linux, if texture storage is available, we now use it and provide the data as RGBA, assuming no conversion by the driver. The swizzling kicks in when we sample this data in the shader. On Windows/Angle we use BGRA as an internal format for texture cache and expect Gecko to provide BGRA data, this should be unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D21965
--HG--
extra : moz-landing-system : lando
Call VRManager::StartFrame directly instead of using a PostTask on Android.
Differential Revision: https://phabricator.services.mozilla.com/D39691
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
