This creates a new method that is used in ApplyChanges and DumpLayer to
calculate the clip rect geometry. Along the way, it eliminates some
redundant outputs:
1) effectiveClip is just a holder of both the position and bounds of the
clip, which are applied seperately by the caller, so the new function
returns them seperately.
2) clipToLayerOffset is just the unscaled negated value of the clip
position, and the only place it is used can tolerate doing the math at the
point of use.
It also reorganizes the logic in DumpLayer a bit to more cleanly separate
the parts that output the wrapping div from the parts that output the img.
It also replaces the use of NS constants with CG constants in
ApplyChanges, for consistency. Hopefully this makes it more clear that
when the clip rect is set and then later unset, the wrapper layer is
restored to its original condition.
Unfortunately, it also re-lints the files it touches, which were somehow
out of compliance with current linting rules, so the changes look much
more extensive than they are.
Differential Revision: https://phabricator.services.mozilla.com/D172289
These checks were designed to identify if we have a logic error in the
display rects or update rects we get from our callers to
HandlePartialUpdate. We've gathered enough evidence that there is such an
error and we've opened Bug 1818540 to address it. There's no longer a good
reason to keep these checks around, as they just crash the browser for
users rather than risk showing them invalid pixels (which we're fairly
sure are valid pixels).
Differential Revision: https://phabricator.services.mozilla.com/D172287
Computed color values will not be in the correct format, closer to the
one specified by the author. This also means that colors accross the
code are stored now as AbsoluteColor or StyleAbsoluteColor. This allows
color space/gamut information to be available for use.
Some animation related test failures had to be changed, because colors
now has greater precision. Animated a color now causes a lot more
animation updates, which was not initially expected. See the bug for
discussion.
Differential Revision: https://phabricator.services.mozilla.com/D171021
Also fix update-angle.py:
* Use shell=True to get ninja to run
* Don't record "/PDBSourcePath:" because it depends on configuration of
the vendoring machine and is otherwise unused, and so uselessly causes
blame noise.
Differential Revision: https://phabricator.services.mozilla.com/D171824
The browser mochitest in this change causes a timeout without this fix since
the overscroll gutter gets stuck thus we will never get "APZ:TransformEnd".
Differential Revision: https://phabricator.services.mozilla.com/D171421
In bug 1787520 and bug 1795614 we added a workaround for a driver bug
on Mali G78 and G710 GPUs. It turns out this also affects the G77, now
that some devices have received software updates containing an updated
driver version. This patch applies the workaround to the G77 as well,
as long as the driver version is affected.
Differential Revision: https://phabricator.services.mozilla.com/D171740
There was a case that RDD process was shut down during WebRender rendering. It happens by RDDProcess shutdown during XPCOMShutdown event. In this case, there could be a widget that nsBaseWidget::Shutdown() has not yet been called.
RDD process must be shutdown after all nsBaseWidget::Shutdown()s are called. gfxPlatform::ShutdownLayersIPC() is called immediately after XPCOMShutdown event in ShutdownXPCOM(). Then the ShutdownLayersIPC() is a good place to handle RDDProcess shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D171313
This is currently used mostly for calculations related to scrollbars,
which are an example of content outside the scroll frame (and in
particular not subject to the zoom of a zoomable scroll frame).
As part of this change, FrameMetrics::
CalculateCompositionBoundsInCssPixelsOfSurroundingContent() is
renamed to CalculateCompositionBoundsInOuterCSSPixels() for brevity.
Differential Revision: https://phabricator.services.mozilla.com/D171142
In principle, the calculated scale should be 1.0 if we are not async-zoomed,
but sometimes things like rounding error can cause the scale to be slightly
off.
Differential Revision: https://phabricator.services.mozilla.com/D171437
There were two problems:
* The line scroll amount was queried in LayoutDevice pixels
and used as CSS pixels without applying the device scale.
* The thumb length was rounded in CSS pixels. To match main
thread behaviour, it needs to be rounded in LayoutDevice
pixels.
Differential Revision: https://phabricator.services.mozilla.com/D171435
Now that NotifySurfaceReady will clean up a 1-pixel strip invalid region,
this change makes HandlePartialUpdate allow a 1-pixel strip invalid
region. This should hopefully make HandlePartialUpdate only crash on the
cases that will also crash NotifySurfaceReady.
Differential Revision: https://phabricator.services.mozilla.com/D171500
There was a case that RDD process was shut down during WebRender rendering. It happens by RDDProcess shutdown during XPCOMShutdown event. In this case, there could be a widget that nsBaseWidget::Shutdown() has not yet been called.
RDD process must be shutdown after all nsBaseWidget::Shutdown()s are called. gfxPlatform::ShutdownLayersIPC() is called immediately after XPCOMShutdown event in ShutdownXPCOM(). Then the ShutdownLayersIPC() is a good place to handle RDDProcess shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D171313
Now that NotifySurfaceReady will clean up a 1-pixel strip invalid region,
this change makes HandlePartialUpdate allow a 1-pixel strip invalid
region. This should hopefully make HandlePartialUpdate only crash on the
cases that will also crash NotifySurfaceReady.
Differential Revision: https://phabricator.services.mozilla.com/D171500
The problem happened by ProcessWebRenderParentCommands() handling with invalid transaction message. When a Tab is moved between Windows, WebRenderBridgeParent::UpdateWebRender() is called. It update mApi and mIdNamespace. Then all WebRender related resources are freed. Then a message with old mIdNamespace from WebRenderBridgeChild becomes invalid. Then we should not handle the obsoleted message.
Differential Revision: https://phabricator.services.mozilla.com/D170563
There are only a few things that could cause the video layer to be
rebuilt:
1) The mMutatedSpecializeVideo flag being set.
2) A new layer object being created to host for the video.
This patch more thoroughly documents instances of case 1 by adding
VIDEO_LOG message to anything that sets the mMutatedSpecializeVideo flag.
It also makes some attempt to identify case 2 by adding a VIDEO_LOG
message whenever we destroy a layer that has ever displayed a video
texture. If a log message like this is followed by a message that a new
video layer is created, it is a strong signal that we are unexpectedly
throwing away our external surface handles when we'd like to keep using
them.
Differential Revision: https://phabricator.services.mozilla.com/D171301
We're headed for a crash, so this change makes gfxCriticalError have more
information that will help us understand the crash. Unlike some other
error-checking code in this class, it is not NIGHTLY_BUILD because the
crash signatures in this Bug are reported in Beta and beyond.
Differential Revision: https://phabricator.services.mozilla.com/D171390
Lock handling is borrowed from D3D11YCbCrImage::SetData(). But ID3D11Texture2D of D3D11TextureData does not use keyed mutex. Since if D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX is used, ID3D11Texture2D could not be used for video overlay. Then D3D11TextureData uses manual synchronization with sync object like D3D11DXVA2Manager::CopyToImage().
Differential Revision: https://phabricator.services.mozilla.com/D171056
Newer Android supports multiple refresh rate that is dynamically changed.
Actually, GeckoView will always pass the refresh rate value to vsync when
getting it first time.
So this fix changes that GeckoView gets the refresh rate when vsync is started.
Differential Revision: https://phabricator.services.mozilla.com/D168665
These crashtests rely upon either a requestAnimationFrame callback or a
MozAfterPaint event. Those currently won't happen when the compositor is
paused, and on Windows these crashtests are occluded, which will now pause
the compositor. To deal with this, we disable the occlusion tracking pref
on Windows. Other platforms seem not to treat the crashtests as occluded,
so their compositors keep running.
Differential Revision: https://phabricator.services.mozilla.com/D171137
The main goal of this is to fix an implementation detail where the
WR code had to read every primitive in the tile even when checking
if a small sub-tile was valid (as the advance amounts of the
primitive dependency array vectors was stored in each primitive).
However, this patch itself is quite a significant optimization, it
improves displaylist_mutate by ~16%.
Instead of maintaining separate arrays for each dependency, use
a single byte array and use peek-poke to store these dependencies.
This simplifies the code for comparing dependencies, and makes the
traversal of sparse index buffers of the primitive array much faster.
Differential Revision: https://phabricator.services.mozilla.com/D170710
Also update some FOG tests that are now incorrect (label limits have been
lifted).
The `default_features = false` on `env_logger` are to avoid a new, duplicate
dependency on hermit-abi.
Differential Revision: https://phabricator.services.mozilla.com/D170816
During font-list initialization, we call Core Text to "activate" the supplemental language fonts,
and potentially any bundled fonts shipped with the app. But this generates an OS notification,
which if we process it will cause a redundant rebuild of our list. So to avoid this, set a flag
when we activate the fonts, telling us that the upcoming notification can be ignored.
Differential Revision: https://phabricator.services.mozilla.com/D171205
Running WebGL on the Renderer thread is causing inexplicable browsertime harness failures. Since there is
still contention with the main thread, moving WebGL work from the CanvasRenderer thread to the Renderer
thread probably has only a small impact on the incidence of bug 1777849.
However, there were other stack size issues fixed there, so we want to leave the stack size fixes in
place.
Differential Revision: https://phabricator.services.mozilla.com/D171147
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
Right now we add global reference to DMABufSurface in VideoFrameSurface when it's allocated by decoder and release it when DMABUFSurfaceImage deleted by MediaSupervisor.
It's not very obvious so in this patch we move DMABufSurface references to DMABUFSurfaceImage only, we add global ref when DMABufSurface is put to DMABUFSurfaceImage
and unref when DMABUFSurfaceImage is deleted.
Differential Revision: https://phabricator.services.mozilla.com/D170625
There were cases that mVideoSwapChain->Present() took long time. It caused low fps and stuttering and lots of dropped frames. When it happens, disabling video overlay could address the problem.
Differential Revision: https://phabricator.services.mozilla.com/D171039
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
It shouldn't be necessary to do this at startup, only on first use of LookupLocalFont.
(We can also simplify things a bit: now that we don't support pre-10.6 systems where
the symbol wasn't present, we don't need to do a runtime dlsym() check.)
Differential Revision: https://phabricator.services.mozilla.com/D170998
In `gfx/config/gfxFeature.{h,cpp}`, it can be observed that a `mozilla::gfx::FeatureState` is
a state machine that collects different "levels" of enabled-ness. To summarize[^1], these are:
1. Default
2. User
3. Environment
4. Runtime
The rules for initializing each of these layers are basically that:
1. At least (1) must be initialized, otherwise, the feature is "unused".
2. Other levels may only be initialized (or re-initialized) if (a) all previous levels were
initialized, and (b) no subsequent levels are initialized. Otherwise, throw an assertion
error.
In the bug we're fixing here, we were attempting to configure the environment level before the user
level, which violates rule 2. Oops! Make sure we init the user level before initting the
environment level.
[^1]: You can find a better description of the intent of each layer at <https://searchfox.org/mozilla-central/rev/75da1dd5d4b9b991f919a41594194eab93cdef62/gfx/config/gfxFeature.h#147-155>.
Differential Revision: https://phabricator.services.mozilla.com/D170764
- Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
- Request full screen update when widget size changes on Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D169905
To run webrender's wrench tests the app needs to read a file to parse
the command line args from, and write a file with the test
output. These files also need to be written and read manually over adb
by the engineer running the tests (or more likely by the
android_wrench.py script).
Currently we use the external data dir for these files. However, on
recent android versions these are no longer accessible to the app
without jumping through some hoops. This patch makes us instead use
the internal data dir. It also makes the app "debuggable" so that
these files can be written to via adb using run-as.
Additionally, we must ensure that the android_wrench.py script uses
run-as instead of root to push and pull the files, as root does not
have permission to do so on recent android versions.
Differential Revision: https://phabricator.services.mozilla.com/D169829
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
- Create wheel transactions for wheel events handled by APZ.
- Group wheel events with the current wheel transaction, so that all
wheel events in a wheel transaction are fired to the same element.
- Store the current event target for the first event in a wheel
transaction to be used for subsequent events.
- Add the dom.event.wheel-event-groups.enabled preference as a feature
flag for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D163484
Simplifies some upcoming work to change how we store these when
updating primitive dependencies during picture cache updates.
Differential Revision: https://phabricator.services.mozilla.com/D170546
It is unclear that we want it enabled for all users and this way we don't have to audit the changes in renderdoc-sys.
We can and should revisit this in the future if we feel like it would be useful to ship with webgpu+renderdoc integration.
Differential Revision: https://phabricator.services.mozilla.com/D170492
For programmatic scrolls, we should respect a users general.smoothScroll
preference. If smooth scrolls are disabled, programmatic scrolls with
behavior: "smooth" should be treated as instant programmatic scrolls.
Differential Revision: https://phabricator.services.mozilla.com/D170110
This patch adds two new prefs, gfx.webrender.scissored-cache-clears
.enabled and .force-enabled to control its status beyond the blocklist.
The former is true by default and allows one to turn the feature off by
flipping it to false. The latter allows one to force the feature on even
if the blocklist disables it. It also adds the status to the decision
log in about:support.
Differential Revision: https://phabricator.services.mozilla.com/D170507
This change makes the VIDEO_LOG only output the first surface sent to a
video layer (whether an AVSampleBufferDisplayLayer or a CALayer), and
notes whenever the video layer has been recreated. This will be helpful in
diagnosing cases degenerate cases where display of video content toggles
between a specialized video layer and a normal layer.
Differential Revision: https://phabricator.services.mozilla.com/D170154
Marian-Vasile Laza
Kershaw Chang
Emilio Cobos Álvarez
Brad Werth
Glenn Watson
Jonathan Kew
stransky
Norisz Fay
Dan Robertson
Tiaan Louw
Kelsey Gilbert
Hiroyuki Ikezoe
Botond Ballo
Jamie Nicol
Teodor Tanasoaia
sotaro
Lee Salzman
Stanca Serban
Marco Castelluccio
Jeff Muizelaar
Updatebot
Cosmin Sabou
Cristian Tuns
Ryan VanderMeulen
Makoto Kato
Daniel Holbert
Chris H-C
Sandor Molnar
Jed Davis
Csoregi Natalia
Timothy Nikkel
Erich Gubler
Iulian Moraru
Dan Robertson
Butkovits Atila
Nicolas Silva
Andrew Osmond
Tom Schuster