Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
We've had a constant of 10 hard-coded there since early days.
Turning it into a configurable number allows us to easier tune it and
debug related issues.
Differential Revision: https://phabricator.services.mozilla.com/D32761
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Moved assertion statement from GetFrameMetrics() to Metrics() so that internal accesses to the frame metrics are covered as well.
Differential Revision: https://phabricator.services.mozilla.com/D32300
--HG--
extra : moz-landing-system : lando
This will make this site only crash in debug, nightly, or dev edition builds.
Differential Revision: https://phabricator.services.mozilla.com/D32852
--HG--
extra : moz-landing-system : lando
When a blob image invalidates, it doesn't always repaint the entire
blob. When we stored the shared surface references in the DIGroup, it
would incorrectly forgot about images referenced by items that were not
invalidated when it repainted. As such, it could free them too early and
cause a crash when rasterizing the blob in the compositor process.
This did not crash most of the time because the image cache would bail
us out. It takes a full minute for the image cache to expire, but the
issue was more readily reproducible when that timeout was shortened.
We now store the references in BlobItemData, on a per display item
basis. This ensures that when any given item is invalidated, it will
continue referencing any resources that it needs.
Differential Revision: https://phabricator.services.mozilla.com/D32820
We now also post the releasing of the shared surface image keys and
external image ID to the main thread. This allows the current
transaction to complete before freeing the surface, which guards against
cases where the surface is referenced and released somehow in the space
of the same transaction.
Differential Revision: https://phabricator.services.mozilla.com/D32861
Remove unecessary Unregister method.
The method is called only once and right prior the parent object gets deleted.
There could be a case where the VRProcessManager destructor gets called before xpcom's shutdown. This would have lead to the now deleted object being called by the Preferences.
Differential Revision: https://phabricator.services.mozilla.com//D32688
--HG--
extra : amend_source : 20b8b4740030ab141856d753a3801b55d607eea3
No functional change. This allows us to support both alpha and non-alpha
variants with the same implementation, in addition to laying the ground
work for QCMS to support BGRA as an input and output.
Differential Revision: https://phabricator.services.mozilla.com/D30820
By default, recycling frames for animated images is enabled. However the
first frame is never recycled because we may need the first frame
immediately if the animation is reset. If only the first frame of an
animation is displayed before shutting down a tab, then it will not
correctly register with the layer state manager prior to its
destruction. This trips an assert incorrectly.
Now we just always register with the layer state manager if recycling is
enabled, and never if recycling is disabled. This allows us to remove
from state information at the cost of requiring a restart to toggle to
recycling pref (which is almost never done now that the feature is
stable.)
Differential Revision: https://phabricator.services.mozilla.com/D32526
No functional change. This allows us to support both alpha and non-alpha
variants with the same implementation, in addition to laying the ground
work for QCMS to support BGRA as an input and output.
Differential Revision: https://phabricator.services.mozilla.com/D30820
We only attempted to shutdow WinCompositorWindowThread if the WebRender thread hadn't not been started.
However, it is possible that the value of gfxVars::UseWebRender() changed since GPUParent::Init got called.
So don't assume anything, shutdown the thread if it still exists.
Differential Revision: https://phabricator.services.mozilla.com/D32609
--HG--
extra : moz-landing-system : lando
If ExternalImageType is just passed from C to rust, it caused crash on non-Windows platform. It was caused by stack corruption. Then &ExternalImageType is used instead of ExternalImageType to bypass the problem.
Differential Revision: https://phabricator.services.mozilla.com/D32436
--HG--
extra : moz-landing-system : lando
This is the last big step towards consistent flattening of transformations.
It includes removing the old "project_to_2d" method from the utils.
Differential Revision: https://phabricator.services.mozilla.com/D32528
--HG--
extra : moz-landing-system : lando
Some time ago (bug 819791), InfallibleTArray and nsTArray become equivalent, so
continuing to use InfallibleTArray here will just lead to confusion.
In addition, the overloaded `RegisterPayload` could take either a single
payload or multiple, so I've split it into
`RegisterPayload(CompositionPayload&)` and
RegisterPayloads(nsTArray<CompositionPayload>&)`
Differential Revision: https://phabricator.services.mozilla.com/D32227
--HG--
extra : moz-landing-system : lando
With desktop zooming, we need to separate the concepts of "may have a distinct
visual viewport" from "has mobile viewport sizing logic applied to it".
This can be thought of as completing the disentanglement of zooming from meta
viewport support started in bug 1459260.
Differential Revision: https://phabricator.services.mozilla.com/D32770
--HG--
extra : moz-landing-system : lando
There doesn't seem to be a reason *not* to do this (merely an omission),
and the results we get without it are messing up somewhere with invalidation
and image cache management.
This is likely just a bandaid over a more serious issue, but if we never observe
that issue, does it exist..?
Differential Revision: https://phabricator.services.mozilla.com/D32833
--HG--
extra : moz-landing-system : lando
Wayland does not support remote drawing for widgets from another process
at this time. As such, it is best to force disable the GPU process, so
that users will be able to get WebRender with Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D32640
Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
It is theorically possible that the WinCompositorWindowThread failed to start. Should this happen, attempting to shut it down will cause shutdown to hang forever.
Differential Revision: https://phabricator.services.mozilla.com/D32602
--HG--
extra : moz-landing-system : lando
The value of the pref may change between start and shutdown.
So we shouldn't rely on that pref to determine if we need to shutdown on thread started earlier if that pref was true.
Differential Revision: https://phabricator.services.mozilla.com/D32601
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
The EGL context must be set before the call to eglSwapInterval to ensure that it will operate on the correct context.
Differential Revision: https://phabricator.services.mozilla.com/D30282
--HG--
extra : moz-landing-system : lando
Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
During the visibility pass, the main clip chain instance for each
primitive is created. In the prim prepare pass, a clip chain instance
is generated for each segment (of primitives that are segmented).
This previously required maintaining the active clip chain stack
during both passes. However, this is not ideal for a number of
reasons: the code is somewhat complicated / error prone and the
segment clip chain building step does more work than required.
This patch changes the segment clip chain building code to set up
the active clip nodes based on the result of the initial clip
chain built for the overall primitive during the visibility pass.
This means that it's no longer necessary to maintain the active
clip chain stack during the prepare pass. This simplifies some
upcoming picture caching changes related to avoiding redundant
cache invalidations, which is the main motivation for the change.
Differential Revision: https://phabricator.services.mozilla.com/D32250
--HG--
extra : moz-landing-system : lando
This is a follow-up to https://phabricator.services.mozilla.com/D30600
Previously, I changed changed the space mapper logic to use the world transformations.
This was seemingly needed because we requrested the relation between primitives and
their clip nodes, which could be in unrelated spatial sub-trees.
However, I believe the change was a mistake, since for clips we should not even try
to get the relative mapping, and clipping is done in world space for these cases.
This change reverts that logic back. ~~Fingers crossed for the try to not show any
asserts firing up inside get_relative_transform.~~ Try is green 🎉
Differential Revision: https://phabricator.services.mozilla.com/D32382
--HG--
extra : moz-landing-system : lando
These tests cause panics in debug mode because of the extra GL error
checking. Tests that are disabled are annotated with the failing
GL call.
Differential Revision: https://phabricator.services.mozilla.com/D32012
--HG--
extra : moz-landing-system : lando
This makes it so that when running reftests, wrench actually terminates
after a panic rather than just hanging. Termination is detectable and so
we can clean up properly instead of waiting until some other layer hits
a timeout.
Differential Revision: https://phabricator.services.mozilla.com/D32010
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Differential Revision: https://phabricator.services.mozilla.com/D30213
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
This adds the base64 encoded color profile to the about:support page in
order to allow us to better diagnose and reproduce color management
issues. We can extract this, decode it and load it directly via the
gfx.color_management.display_profile pref.
Now they both work in opt builds, and they both work with advanced layers.
For consistency, layers.dump-client-layers is also modified to work in
opt builds.
Differential Revision: https://phabricator.services.mozilla.com/D34413
--HG--
extra : moz-landing-system : lando
With this change, the tests in question pass on desktop, except for
scrollbar-zoom-resolution-2.html which is annotated as failing.
Differential Revision: https://phabricator.services.mozilla.com/D32775
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
In bug 1527182 we made it so that APZ can directly drag-scroll scrollframes
that are inside SVG effects, because that's possible with WR on the compositor.
However the code changed in that bug was meant to be kept in sync with
a second piece of code. The second piece of code controls the generation
of ScrollInfo items for scrollframes inside SVG effects - since we can
APZ-scroll them with WR, we don't need the scrollinfo item anymore.
Producing the scrollinfo item was changing the structure of the APZ tree
in terms of where the transform ended up, and was causing badness with
untransforming the drag mouse events.
This patch adds a test that covers the scenario and also corrects the defect
by bringing the two bits of code back in sync.
Differential Revision: https://phabricator.services.mozilla.com/D31647
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
Also remove extra plumbing from WebGLShaderValidator, moved directly
into WebGLShader.
Differential Revision: https://phabricator.services.mozilla.com/D31567
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
--HG--
extra : moz-landing-system : lando
This makes DrawTarget and ReadTarget no longer require a borrow
on a texture. This was previously fine, but in the near future
WR will be rendering picture caching surfaces directly into
texture handles. To allow this, we need to remove the borrow check
requirement on DrawTarget for rustc.
Differential Revision: https://phabricator.services.mozilla.com/D31390
--HG--
extra : moz-landing-system : lando
The CompositorBridgeParent won't have a LayerManager when running with
WebRender, so attempting to take a composition recording will cause a crash. We
now silently fail to take the recording since recording is not supported on Web
Render.
Differential Revision: https://phabricator.services.mozilla.com/D31169
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
This moves the existing constants into a ReftestEnvironment which
encapsulates it a bit better. Also this fixes the incorrect "debug" cfg
check to "debug_assertions" which is more correct.
Differential Revision: https://phabricator.services.mozilla.com/D31181
--HG--
extra : moz-landing-system : lando
This moves the existing constants into a ReftestEnvironment which
encapsulates it a bit better. Also this fixes the incorrect "debug" cfg
check to "debug_assertions" which is more correct.
Differential Revision: https://phabricator.services.mozilla.com/D31181
--HG--
extra : moz-landing-system : lando
ColorMatrix is rarely used but takes most space in the Filter enum.
This removes 44 bytes from the enum and all structs that embed it.
Differential Revision: https://phabricator.services.mozilla.com/D30910
--HG--
extra : moz-landing-system : lando
