This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Before Bug 1570869, new frame was generated if WR does not have a pending frame build task. But since Bug 1570869 fix, there is a case that new frame generation does not happen even when WR does not have a frame build task.
Differential Revision: https://phabricator.services.mozilla.com/D47045
--HG--
extra : moz-landing-system : lando
Move DeviceReset handling before the assert. It is OK, since RendererOGL instance is not re-used after the DeviceReset. It is replaced by a new RendererOGL.
Differential Revision: https://phabricator.services.mozilla.com/D47036
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
It is a preparation of Bug 1460499. It adds RenderDXGITextureHostOGL::GetD3D11Texture2D() for use by dc layer.
Differential Revision: https://phabricator.services.mozilla.com/D46928
--HG--
extra : moz-landing-system : lando
Preparation work for adding DirectComposition support. It does not add a new functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46429
--HG--
extra : moz-landing-system : lando
IDCompositionDevice::Commit needs to be called when there is an update to DirectComposition. RenderCompositorANGLE updates DirectComposition only during initialization. Then it is not necessary to call the function in EndFrame().
Differential Revision: https://phabricator.services.mozilla.com/D46249
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
We compute the preserved bounds for each item and see if it's
contained in the invalid area. The gecko side will do the same
computation.
Appologies for duplicating euclid with Box2d type. We can deal with
that in a followup.
The asserts are disabled for now. I tried reenabling them and they
triggered. I haven't had a chance to figure out if they are still
valid.
Differential Revision: https://phabricator.services.mozilla.com/D45283
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
This also removes a dependency on rand 0.4 getting it closer to being
able to remove that.
Differential Revision: https://phabricator.services.mozilla.com/D45710
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
Falls back to 'false' in non-nightly builds instead of using the gfx.webrender.start-debug-server pref, which is only available in nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D44743
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
When Windows version is mort than 1903 and GPU is intel GPU, it could cause flickering with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. See Bug 1556634. As a short term workaround, use DXGI_ALPHA_MODE_PREMULTIPLIED instead of DXGI_ALPHA_MODE_IGNORE at SwapChain.
Differential Revision: https://phabricator.services.mozilla.com/D41713
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--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
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
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
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
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
A few potential error cases were being unwrapped, resulting in a very
small number of crashes. These errors can be safely ignored as the
program cache is non-critical, so this change makes us log the error
and continue rather than panicking.
Differential Revision: https://phabricator.services.mozilla.com/D38650
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
Without CoreAnimation, back-pressure was applied by SwapBuffers: On a
double-buffered NSOpenGLContext which is bound to an NSView, [context flushBuffer]
waits for the previous frame to be finished. With CoreAnimation, the context
is no longer bound to an NSView, and SwapBuffers acts as a regular glFlush.
glFlush on its own does not prevent overproduction.
If we submit GPU work at a faster rate than the GPU can handle, we end up
delaying the window server's GPU work. This can cause the window server to skip
frames. So even if Gecko can produce frames at 60FPS, the window server might
only present those frames at 30FPS, skipping every second frame.
Differential Revision: https://phabricator.services.mozilla.com/D26412
--HG--
extra : moz-landing-system : lando
This is a follow up to bug 1564655. It removes the offset from ToDeviceSpace
and thus moves item rects into absolute space which is now the same coordinate
space as the recordings are in.
We also adjust item bounds for fallback blobs.
Some additional changes that need happen to:
1. In Moz2DImageRenderer we can reunify the origin because the recording and
the recording metadata return to using the same coordinate space.
2. The calls to PushLayer can return to using the item bounds
which are now in the same coordinate space.
3. This dirty rect which remains in images space is adjusted during merging.
Differential Revision: https://phabricator.services.mozilla.com/D38015
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
--HG--
extra : moz-landing-system : lando
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : moz-landing-system : lando
This removes duplication and makes it a bit safer by using ConvertFromBytes to
do an unaligned read of the indexOffset.
Also, inner classes can't have template methods. Who knew.
Differential Revision: https://phabricator.services.mozilla.com/D37870
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This minimizes regret by requiring T: Copy and switches
to read_unaligned() because the pointer can be unaligned.
Differential Revision: https://phabricator.services.mozilla.com/D37861
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : source : cb1d78b00e25dd7fcfec86216c7a83c85ce9a982
extra : histedit_source : 68a31189f05998ba3b8a29a624d7ebe37636c4d9
sotaro
thomasmo
Ciure Andrei
Timothy Nikkel
arthur.iakab
Noemi Erli
Glenn Watson
Andreea Pavel
Jeff Muizelaar
Nicolas Silva
Andrew Osmond
Bastien Orivel
Gurzau Raul
Markus Stange
Kristen Wright
Sylvestre Ledru
Mike Hommey
Connor Brewster
Dzmitry Malyshau
Barret Rennie
Jean-Yves Avenard
Narcis Beleuzu
Cosmin Sabou
Nicholas Nethercote
Alexis Beingessner
Martin Stransky
Jamie Nicol
Csoregi Natalia
Jeff Muizelaar
Mihai Alexandru Michis
Daniel Varga
Brindusan Cristian