We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
* Templatize ProducerView/ConsumerView/(Sync)CommandSource/(Sync)CommandSink to allow both Pcq and Ipdl versions, as the client code is identical.
* Rename Producer/Consumer -> PcqProducer/PcqConsumer.
Differential Revision: https://phabricator.services.mozilla.com/D68259
In particular this will pick up any hit-test flags set on individual items
inside a blob, and ensure the hit-test info emitted to APZ for the blob includes
those flags.
Differential Revision: https://phabricator.services.mozilla.com/D69205
It's no longer needed with the recent fix to how rectangle prim
and clip rects are stored. It's also a performance win, reducing
the amount of work done when comparing primitive dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D72794
It's no longer needed with the recent fix to how rectangle prim
and clip rects are stored. It's also a performance win, reducing
the amount of work done when comparing primitive dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D72794
In particular this will pick up any hit-test flags set on individual items
inside a blob, and ensure the hit-test info emitted to APZ for the blob includes
those flags.
Differential Revision: https://phabricator.services.mozilla.com/D69205
Part 1 - support RGB external surfaces for promotion to compositor
surfaces; add new shader permutations to handle all buffer kinds.
Set the promotion flag when the pixel format has no alpha, or when the
texture provider can guarantee all-solid alpha values.
Differential Revision: https://phabricator.services.mozilla.com/D71120
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This is the anti-climactic end of the patch series.
I set out in this bug to get this test case to pass with apz.allow_zooming.
It took all these changes to do so without regressing other tests.
Differential Revision: https://phabricator.services.mozilla.com/D69644
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
The implementation was already only using the scroll id, so there is no
functional change, but this change will make it easier to new call sites
to come up with the function's inputs.
Differential Revision: https://phabricator.services.mozilla.com/D68277
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
This is to facilitate call sites that need to incorporate the transform into
a larger transform matrix rather than immediately applying the callback
transform to a point.
Differential Revision: https://phabricator.services.mozilla.com/D68275
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
The RenderBackend can be sent an `invalidate_rendered_frame` flag to
indicate that the current rendered frame is invalid. This is useful
when the platform requires a render, eg when starting or resuming the
app on Android. Upon receiving this flag, the render backend will set
a variable `doc.rendered_frame_is_valid = false`. Later on it will
decide to skip rendering only if this variable is true, so by setting
the invalidate flag we should be able to ensure the next render will
occur.
However, the RenderBackend also tries to skip renders which it
determines are not required. Currently it does this by setting
`doc.rendered_frame_is_valid = true` if it decides the frame is a
no-op. This overwrites the previous value set by the
`invalidate_rendered_frame` flag, meaning webrender skips renderering
even though the platform has requested it.
This was resulting in the GVE app showing a black screen on startup,
and Fenix temporarily showing a black screen whilst opening a new tab,
because despite WebRenderBridgeParent requesting an invalidation
immediately on startup, webrender ignored that request until it
decided it actually had content to paint.
To fix this, the logic should be flipped. The value of
`doc.rendered_frame_is_valid` must be remembered across document
updates rather than defaulting to false. And instead of setting it
true if webrender thinks the frame is a no-op, we must set it false if
webrender thinks the frame is *not* a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D72600
Refer to bug 1630781 comment 11 for a more detailed explanation of the problem.
A quick summary is that prior to this patch, the sampling operation involved
these steps:
- sample stored APZ state for composition
- advance animations to next vsync
- update stored APZ state to the one just computed
When sampling occured twice within a vsync interval, the stored APZ state
calculated at the end of the first sampling would be produced in the second
sampling, resulting in non-smooth scrolling. Note that the second and third
steps would only run once per vsync interval, but that was sufficient to cause
the problem.
With this patch, the order of the steps is reordered:
- update stored APZ state to that computed in the last vsync interval
- advance animations to next vsync and save it in the queue
- sample stored APZ state for composition
With this ordering (and with the first two steps only running once per vsync
interval), the third step now emits consistent data even if the steps are run
multiple times in a vsync interval. It does mean that the mSampledState deque
can have up to two items in it (front() being the state for the current vsync
interval, and back() being the state computed for the next vsync interval).
Although this problem only affected the WR codepath in practice, it could in
theory occur with the non-WR codepath too, if we for some reason ran the
TransformShadowTree code multiple times in a vsync interval. This patch updates
both codepaths with the new order of steps.
Differential Revision: https://phabricator.services.mozilla.com/D72046
Again, functionally this is a no-op since instead of replacing the back()
element, we do an emplace_back() followed by a pop_front().
Differential Revision: https://phabricator.services.mozilla.com/D72044
The deque always has size 1, so this patch is functionally a no-op. It sets up
the usage of front() and back() to allow holding more than one item in a future
patch.
Depends on D72042
Differential Revision: https://phabricator.services.mozilla.com/D72043
No functional changes intended here, just code getting moved into a helper
class. Note that this patch folds RecalculateCompositedLayoutViewport into
ClampCompositedScrollOffset since there are no longer any independent callers
of the former function (as of bug 1627716).
Depends on D72041
Differential Revision: https://phabricator.services.mozilla.com/D72042
No functional change, since everything was safe already. But this propagates
the proof-of-lock a little further to make it more obvious that fields are
safely accessed.
Depends on D72040
Differential Revision: https://phabricator.services.mozilla.com/D72041
Having to think about multiple codepaths adds complexity and it doesn't seem
like we're going to turn this pref back off anytime soon.
Differential Revision: https://phabricator.services.mozilla.com/D72040
