This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Depends on D89863
Differential Revision: https://phabricator.services.mozilla.com/D89864
This is just moving code to make it reusable in APZ. As part of this, I replace
use of Preferences::* with the StaticPrefs::* API, because we can't use
Preferences:: in the GPU process and we'll want to be able to invoke this code
from there.
Differential Revision: https://phabricator.services.mozilla.com/D89665
This is used for scrolls of type eSmoothMsd that the main-thread sends over,
and for scroll snapping. For consistent naming let's call this smooth msd.
Differential Revision: https://phabricator.services.mozilla.com/D89662
This is the only place that uses the mSmoothScrollOffset any more, and it
doesn't really need to as a local variable suffices.
Differential Revision: https://phabricator.services.mozilla.com/D88748
This rewrites a big chunk of the NotifyLayersUpdated code (most of the code that
deals with incoming scroll requests from the main-thread) to instead iterate
through the list of ScrollPositionUpdates on the metadata and apply them in
order. A bunch of the ApplyXXXUpdateFrom functions on FrameMetrics have their
innards deduplicated and boil down to a single line, which is then inlined, so
those functions get removed entirely.
Note that this rewrite doesn't yet handle all the possible types of
ScrollPositionUpdate instances, just the ones that the old code handled. In the
future this support will be fleshed out with tests to exercise the relevant
codepaths.
There is also a change to nsGfxScrollFrame which slightly modifies the semantics
of mApzScrollPos to handle the case where multiple relative scrolls happen in a
single transaction. As the implementation now requires multiple relative
ScrollPositionUpdates rather than a single "unified" relative scroll in the
FrameMetrics, we need to update mApzScrollPos for each relative
ScrollPositionUpdate we generate.
Differential Revision: https://phabricator.services.mozilla.com/D88744
The existing ScrollUpdateInfo that is used to store a "paint-skipped scroll" for
empty transactions is very similar to the new ScrollPositionUpdate class, so
we can delete the former and use the latter instead.
The important part of this change is that when applying the pending info to
a FrameMetrics, we now also append the ScrollUpdateInfo to the mScrollUpdates
list on the ScrollMetadata. This aligns the code with the previous few patches,
where we duplicate the scroll information in both the regular FrameMetrics
fields and the ScrollMetadata::mScrollUpdates array.
Note that the existing code may have a defect when multiple paint-skip scrolls
occur in a single transaction; only the newest one is kept. In the case where
the last paint-skip is an absolute scroll, this is fine, but a relative scroll
may end up clobbering a previous absolute scroll. This patch explicitly detects
the scenario with multiple paint-skip scrolls and bails out to a full paint
transaction. As a followup it should be possible to relax this restriction by
storing an array of pending ScrollPositionUpdate instances.
Differential Revision: https://phabricator.services.mozilla.com/D88743
Every time the scroll generation is incremented, we now also attach the
equivalent ScrollPositionUpdate instances to the metadata.
Differential Revision: https://phabricator.services.mozilla.com/D88742
This adds a ScrollPositionUpdate class. Code in nsGfxScrollFrame creates
instances of these classes every time the scroll generation is incremented,
and saves them to an array. The array is sent in the scroll metadata to the
compositor as part of a paint transaction.
Currently this data is not used at all on the APZ side, and exists alongside
(independently of) the existing scroll fields, so this patch should not have
any functional effects.
Differential Revision: https://phabricator.services.mozilla.com/D88741
AHardwareBuffer could remove several limitations of android::SurfaceTexture.
File descriptor usage of current implementation is not efficient. It is going to be addressed by Bug 1663381.
Differential Revision: https://phabricator.services.mozilla.com/D89232
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
APZ can sometimes indicate that it will be consuming touch events, even though
the touch-action properties prohibit it. This can happen if, for example, APZ
is waiting on the main-thread for accurate touch-action information. In such
cases, the main thread has enough information to filter out these false positives.
This patch makes it do that, by plumbing the allowed touch behaviors into
the APZEventState code that triggers the pointercancel event.
Differential Revision: https://phabricator.services.mozilla.com/D89303
Use ID3D11VideoProcessor for video frame rendering.
WebRenderError::VIDEO_OVERLAY does not cause disabling WebRender. It just change gfxVars::UseWebRenderDCompVideoOverlayWin() to false.
Differential Revision: https://phabricator.services.mozilla.com/D88763
We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
libyuv library used for software decode UYV video formats to RGB produces also alpha for RGBX formats.
As we use OP_OVER in Basic compositor, the alpha channel is copied to final surface which is sent to window manager.
When alpha X11 visual is used, the bogus alpha information is used for blending and the video is transparent,
co we need to clear the alpha information from the video surface.
Differential Revision: https://phabricator.services.mozilla.com/D88558
Release fence is delivered from RenderCompositorEGL to WebRenderImageHost via AsyncImagePipelineManager. And the fence is sent to client side by ImageBridgeParent.
Differential Revision: https://phabricator.services.mozilla.com/D88158
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
The new promiseMouseDragEvent function is an async promise-returning copy of
the code in dragVerticalScrollbar. Eventually we should just make all this code
using async/promise but that's for another day.
Differential Revision: https://phabricator.services.mozilla.com/D88894
The new promiseMouseDragEvent function is an async promise-returning copy of
the code in dragVerticalScrollbar. Eventually we should just make all this code
using async/promise but that's for another day.
Differential Revision: https://phabricator.services.mozilla.com/D88894
For android SurfaceTexture and AndroidHardwareBuffer, GPU/hardware task end could be checked by android fence. Then their TextureHost do not need to be held by AsyncImagePipelineManager::mTexturesInUseByGPU.
Differential Revision: https://phabricator.services.mozilla.com/D88239
This advances the migration by 25% each release, starting in release 83 and
completing in 86. The migration code can be removed in the 86 nightly cycle
(or anytime after that).
Differential Revision: https://phabricator.services.mozilla.com/D88453
There already exist 3 implementations of this stuff and I don't want to add another one for the WR OS compositor path.
(The three implementations are: CompositorScreenshotGrabber, MLGPUScreenshotGrabber and RendererScreenshotGrabber.)
The interface has been designed in such a way that the MLGPU and WR implementations should be able to use it but I
haven't written the code to convert them.
Differential Revision: https://phabricator.services.mozilla.com/D59157
If the content response timeout is longer than the long-tap delay (which is
true given the current default pref values), and a touch block waits for the
entire content response timeout period, then the long-tap gesture gets delayed
by the difference in the timeouts. This can happen if the input block remains
in the slop state (and therefore never dispatches a touchmove to content,
thereby preventing the content from producing a content response). This patch
catches this scenario and installs a long-tap timeout in the InputQueue to
force the input block along.
Differential Revision: https://phabricator.services.mozilla.com/D88010
Touch inputs that go to the GestureEventListener often have to wait in the
InputQueue for some time as well, until the content response arrives. However,
that delay is not accounted for in the GestureEventListener delays. This can
result in the gesture being artificially delayed from a user's perspective.
This patch computes the amount of time the input event already waited in the
input queue, and shortens the delays used in the GestureEventListener
accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D88009
