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
This adds the last remaining explicit API for defining clips of
a specific type, and ports wrench and examples to use them.
Differential Revision: https://phabricator.services.mozilla.com/D72284
This allows defining rectangle clips directly, rather than via
the generic clip region methods.
This patch doesn't make use of it in Gecko yet, but it will do
once we add the remaining rounded rect API.
Differential Revision: https://phabricator.services.mozilla.com/D72268
Bug 1632096 added the capability to shared gl context with WebRender. This bug extends the support to non shared gl context.
Differential Revision: https://phabricator.services.mozilla.com/D72579
They aren't used, so can easily be removed as the first part of
this seried of patches.
If this functionality is ever required, it can be handled by the
caller defining complex clip nodes explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D72261
The information comes with SetDisplayList messages but was applied before scene building instead of during scene swap, which breaks the transaction model and looks like a bug.
Differential Revision: https://phabricator.services.mozilla.com/D71934
Separating out the generic clip definition API into image masks
(and other types in future) makes the serialized data smaller. More
importantly, it will allow us to simplify some of the WR clip internals
in future and optimize the performance spent in clip chain handling.
Differential Revision: https://phabricator.services.mozilla.com/D72125
This is not used, so we can remove it as the first part of modifying
the public clip API in order to allow some internal optimizations.
If callers ever want to make use of this in future, it can be
achieved by placing an image mask clip node in the clip chain for
the primitives in the scroll layer.
Differential Revision: https://phabricator.services.mozilla.com/D72099
A previous patch attempted to optimize only GL or GLES shaders,
depending on the target platform. However, it was trying to detect the
platform by using `cfg!(target_os = {})`, but as this is in a
build script that actually detects the host platform instead. This
resulted in the wrong version of shaders being optimized, and
therefore falling back to unoptimized shaders at runtime.
This fix uses `env::var("CARGO_CFG_TARGET_OS")` instead, which works
correctly in build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D72127
DocumentView has a mix of members that affect scene building and memebers that change frame to frame. These need to be updated at different rates and more importantly follow the respective flow of scene and frame transactions, which wasn't done properly before this change.
Depends on D71781
Differential Revision: https://phabricator.services.mozilla.com/D71927
The goal is to move this code out of the render backend to avoid requiring the messages to transit through this thread. Other similar changes are in progress.
Differential Revision: https://phabricator.services.mozilla.com/D71781
Include the inflation factor from all drop-shadow filters when
calculating the overall inflation factor for a surface.
This doesn't fix cases with large offsets, which is a larger amount
of work to fix, but it fixes the common case and the referenced
case in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D71878
Include the inflation factor from all drop-shadow filters when
calculating the overall inflation factor for a surface.
This doesn't fix cases with large offsets, which is a larger amount
of work to fix, but it fixes the common case and the referenced
case in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D71878
The full set of optimized shaders can be quite large, so only optimize
for the GL version we expect to be used on the target platform. That
is GLES on Android and Windows (where we presume ANGLE is being used),
and GL elsewhere.
If a different GL version is used we will simply fall back to the
unoptimized shaders.
Depends on D71905
Differential Revision: https://phabricator.services.mozilla.com/D71945
The list of pre-optimized shaders was being generated in a
non-deterministic order, causing large build time regressions. This
sort the list of shaders before writing them to the shaders.rs file.
Differential Revision: https://phabricator.services.mozilla.com/D71905
In bug 1589669 we ensured that webrender snaps the asynchronous scroll
offset correctly. Prior to that, the fractional offsets of picture
cache tiles were changing every frame, leading to excessive picture
cache invalidation. Since then, however, we have landed bug 1609002,
which made it so that asynchronous scrolling is split in to the scroll
offset and the visual viewport transform. The visual viewport
transform is sent to webrender as an animated transform property, and
since this was not being snapped it regressed the picture caching
invalidation fix. This change ensures that offset is snapped
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D71920
The code is untested, and mostly obsoleted by (multi) frame captures.
Also it gets in the way of some other changes I need to make.
Differential Revision: https://phabricator.services.mozilla.com/D71372
Now that the capture code is gone, we don't use these serde implementations. They get in the way of changing the way transactions are represented so I'd like to remove a bunch of them for now.
Differential Revision: https://phabricator.services.mozilla.com/D71604
