If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
`gecko_profiler_add_text_marker` was being passed a character pointer and a
length to construct a `nsDependentCString`. However, these values were coming
from a Rust `&str`, which is not null-terminated, causing an debug assertion to
be hit (and possible memory safety issues if mishandle the string). We now
construct an `nsDependentCSubstring` instead.
Differential Revision: https://phabricator.services.mozilla.com/D24032
--HG--
extra : moz-landing-system : lando
By Bug 1526213, WebRenderBridgeParent::RecvEmptyTransaction() does not handle a case that resource update is handled by WebRenderTextureHostWrapper. In this case, txn.IsResourceUpdatesEmpty() became true and the function thought there was no resource update and the function returned DidComposite soon to client side. Then it caused a heavy over production of SharedSurface_ANGLEShareHandle if GPU is not powerful.
Differential Revision: https://phabricator.services.mozilla.com/D22454
By Bug 1526213, WebRenderBridgeParent::RecvEmptyTransaction() does not handle a case that resource update is handled by WebRenderTextureHostWrapper. In this case, txn.IsResourceUpdatesEmpty() became true and the function thought there was no resource update and the function returned DidComposite soon to client side. Then it caused a heavy over production of SharedSurface_ANGLEShareHandle if GPU is not powerful.
Differential Revision: https://phabricator.services.mozilla.com/D22894
--HG--
extra : moz-landing-system : lando
The way we control APZ zooming in WebRender is by inserting an animation
property placeholder on a WR stacking context, and then having APZ
update the animation transform value with the proper matrix at composite
time.
Previously, the stacking context being used was the rootmost
stacking context in the content process. However this doesn't work for
zoomable content in the UI process (e.g. about:support), and after
recent changes, also wraps display items that should not be affected by
zoom (e.g. scrollbars or the background color item).
This patch moves the animation property placeholder so that it
corresponds to the newly added nsDisplayAsyncZoom display item, which
corrects both of the above problems and is conceptually in line with the
desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D21795
--HG--
extra : moz-landing-system : lando
The goal of this change was to simplify the semantics of our document placement and split the logical elements inside (display list) from the actual screen rectangle occupied by a document.
To achieve that, we introduce the framebuffer space for things Y-flipped on screen.
We fix the frame outputs, so that they get produced on the first frame without loopback from the frame building to scene building.
Differential Revision: https://phabricator.services.mozilla.com/D21641
--HG--
extra : moz-landing-system : lando
The goal of this change was to simplify the semantics of our document placement and split the logical elements inside (display list) from the actual screen rectangle occupied by a document.
To achieve that, we introduce the framebuffer space for things Y-flipped on screen.
We fix the frame outputs, so that they get produced on the first frame without loopback from the frame building to scene building.
Differential Revision: https://phabricator.services.mozilla.com/D21641
--HG--
extra : moz-landing-system : lando
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/composite/ContainerLayerComposite.cpp:132:6 [-Wmissing-prototypes] no previous prototype for function 'TransformLayerGeometry'
gfx/layers/composite/LayerManagerComposite.cpp:1409:6 [-Wmissing-prototypes] no previous prototype for function 'ComputeVisibleRegionForChildren'
gfx/layers/composite/LayerManagerComposite.cpp:234:6 [-Wmissing-prototypes] no previous prototype for function 'ShouldProcessLayer'
gfx/layers/composite/TiledContentHost.cpp:156:6 [-Wmissing-prototypes] no previous prototype for function 'UseTileTexture'
gfx/layers/ipc/CompositorBridgeParent.cpp:1827:6 [-Wmissing-prototypes] no previous prototype for function 'EraseLayerState'
gfx/layers/ipc/CompositorBridgeParent.cpp:2140:6 [-Wmissing-prototypes] no previous prototype for function 'UpdateIndirectTree'
gfx/layers/opengl/OGLShaderProgram.cpp:28:6 [-Wmissing-prototypes] no previous prototype for function 'AddUniforms'
Differential Revision: https://phabricator.services.mozilla.com/D20265
--HG--
extra : source : f5653a8b1bc5a02cf899fe87cb3ebc9796b0b0b1
extra : histedit_source : 4f44f15098c42b4b1fa141de7b8593c128b58596
By using WebRenderTextureHostWrapper for canvas, we could avoid triggering frame build on WebRender backend if WebRenderTextureHostWrapper is only change.
Differential Revision: https://phabricator.services.mozilla.com/D19896
--HG--
extra : moz-landing-system : lando
r?njn only because this is the first example that adds any actual subcategories.
Differential Revision: https://phabricator.services.mozilla.com/D11340
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.
Differential Revision: https://phabricator.services.mozilla.com/D19699
This patch is an attempt to separate the two and avoid accidentally getting into an inconsistent state.
WebRenderImageData manages resources for images that are shared with webrender, while WebRenderFallbackData manages state to render content, in most case in a blob image.
if the fallback data needs to render into a TextureClient, it creates a WebRenderImageData to hold on to the shared texture, but does not inherit from it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19565
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
It turns out that setting the parent link on a clip chain is no longer
needed (and probably hasn't been since WR started applying a stacking
context's clip to the SC's contents). In fact it can produce incorrect
behaviour in some cases, because it doesn't match the semantics of
Gecko's clip chains. This removes the parent link on the Gecko side and
adds a test for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18101
--HG--
extra : moz-landing-system : lando
WebRenderBridgeParent::RemoveEpochDataPriorTo() does not check when animation is added by using epoch. Then there is a case that animation is deleted too early.
Differential Revision: https://phabricator.services.mozilla.com/D17799
--HG--
extra : moz-landing-system : lando
This lets us get some of the advantages of clipped blobs by drawing less of the
fallback blob while still not needing to rerecord and redraw the blob
completely during scrolling because of the changing clip rect. It drops
the number of tiles requested on a reduced test case reduced from the Googled
doc from 60 to a much more reasonable number.
Differential Revision: https://phabricator.services.mozilla.com/D17180
Instead of setting the item PaintRect to paintBounds we intersect it with the
BuildingRect. This properly reduces the size based on clips and gives a big
performance improvement for clipped nsDisplayFilter items because we call
CreateSimiliar surface for the size of building rect instead of the bounds of
the item.
Differential Revision: https://phabricator.services.mozilla.com/D17179
This changes the calculation to match what we do for SVG blobs.
Notably, it takes the residual into account when computing the area
we want to paint into. This makes a difference if the fallback
is happening at a fractional offset.
Differential Revision: https://phabricator.services.mozilla.com/D17178
We already avoid scene rebuilding for animated image frame updates, but
we can easily apply this to still images. If the decoding is happening
slowly and in chunks for some reason (really large image, slow network),
then we may save some work.
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
The only thing using both was perspective, but that's not really needed with the current setup.
This more closely matches Gecko, too.
Differential Revision: https://phabricator.services.mozilla.com/D16764
--HG--
extra : moz-landing-system : lando
So that it's easily available during painting.
The flag is set based on nsIPresShell::mIsFirstPaint, but the pres shell
flag is cleared at the beginning of the paint, so we can't query it from
the pres shell during the paint.
Differential Revision: https://phabricator.services.mozilla.com/D16237
--HG--
extra : moz-landing-system : lando
References to shared surfaces are already kept alive for the blob in the
content process, and it also ensures an image key is created to ensure
any release of the surface is delayed until the next epoch. Wrapped
shared surfaces (when used in an animation which is recycling its
surfaces) did not get an image key created which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D16191
If an item in a blob image gets a new parent container which clips it to
a smaller area than it was previously, we need to ensure the dirty rect
does not take into account the new clip when determining the old
intersection area. Instead now all old rects for an image are clipped to
the image bounds, rather than the image bounds clipped to the aggregate
of the ancestor containers.
Differential Revision: https://phabricator.services.mozilla.com/D16855
We are using the unrounded dest rect to calculate the image decode size
in ComputeImageContainerDrawingParameters, while passing the rounded
dest rect to WebRender. This mismatch causes images to be decoded to one
size and display at another, cause some visual distortions. Using the
correct rect seems to allow us to remove the extra snapping logic added
to work around this.
At this time, how we snap is different between WebRender and
non-WebRender in general. This patch will likely morph again once we
bring the two models closer together.
Differential Revision: https://phabricator.services.mozilla.com/D15739
If an item in a blob image gets a new parent container which clips it to
a smaller area than it was previously, we need to ensure the dirty rect
does not take into account the new clip when determining the old
intersection area. Instead now all old rects for an image are clipped to
the image bounds, rather than the image bounds clipped to the aggregate
of the ancestor containers.
Differential Revision: https://phabricator.services.mozilla.com/D16855
WebRender can handle small image without much overhead. Allowing
small images will give us more predictable behaviour because
we don't end up merging things unneccessarily.
Differential Revision: https://phabricator.services.mozilla.com/D16337
--HG--
extra : moz-landing-system : lando
So that it's easily available during painting.
The flag is set based on nsIPresShell::mIsFirstPaint, but the pres shell
flag is cleared at the beginning of the paint, so we can't query it from
the pres shell during the paint.
Differential Revision: https://phabricator.services.mozilla.com/D16237
--HG--
extra : moz-landing-system : lando
References to shared surfaces are already kept alive for the blob in the
content process, and it also ensures an image key is created to ensure
any release of the surface is delayed until the next epoch. Wrapped
shared surfaces (when used in an animation which is recycling its
surfaces) did not get an image key created which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D16191
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Discard animations after calling WrBridge()->EndTransaction(). It updates mWrEpoch in WebRenderBridgeParent. The updated mWrEpoch is necessary for deleting animations at the correct time.
Differential Revision: https://phabricator.services.mozilla.com/D15799
This shouldn't change any behaviour, just puts the code into a separate function so that it's easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D15794
--HG--
extra : moz-landing-system : lando
CONTENT_FRAME_TIME_VSYNC is more meaningful metric because it actually
starts at the beginning of the vsync making it easier to reason about
missing frames. It makes more sense for CONTENT_FRAME_TIME_REASON wants
to use this same starting point.
Differential Revision: https://phabricator.services.mozilla.com/D15790
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time.
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time.
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time..
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
It perhaps makes more sense to use the start of refresh but I'd like to switch
to the start of the paint so that we get more consistent results between the
two probes.
Differential Revision: https://phabricator.services.mozilla.com/D15236
--HG--
extra : moz-landing-system : lando
Currently we use the regular fallback path for the mask images used by blobs.
This isn't really the best fit and is causing test failures with the current
blob re-coordination patches.
This changes the code to be more FrameLayerBuilder and handles
invalidation of the mask without using FrameLayerBuilder.
Differential Revision: https://phabricator.services.mozilla.com/D14779
--HG--
extra : moz-landing-system : lando
Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
This commit contains the Gecko-side changes from WebRender PR#3277:
- Dedicated DirtyRect type.
- Separate the blob image APIs from regular image ones.
Differential Revision: https://phabricator.services.mozilla.com/D12463
--HG--
extra : moz-landing-system : lando
This lets us avoid having to put usize in the exported signatures from bindings.rs
It also avoids a heap allocation when defining a clip chain.
Differential Revision: https://phabricator.services.mozilla.com/D12785
--HG--
extra : moz-landing-system : lando
Here we make use of the parts added in parts 1 and 2 to hold onto
recycled surfaces for as long as necessary to prevent the animated image
decoder from reusing them until WebRender is done with them.
Differential Revision: https://phabricator.services.mozilla.com/D10902
When we replace the external image ID an image key points to, the
previous external image ID may still be used by WebRender. We currently
wait until the frame has been rendered to release our hold on said
surface. With this patch, we will communicate the image key and previous
external image ID pairing to the owning process when releasing to let it
know that it can reuse it (e.g. for an animated image). Additionally we
now use the new textures updated checkpoint which should happen sooner
than the frame rendered checkpoint, but guarantee that WebRender is no
longer using the old external image ID.
Differential Revision: https://phabricator.services.mozilla.com/D10897
Previously, WebRender ignored clip_node_id on the clip/scroll stack
when pushing clips or reference frames. This got fixed to be more consistent in:
https://github.com/servo/webrender/pull/3315
Now Gecko can use the clip chains generated for display items naturally,
instead of smuggling the last clip through the scroll_node_id, which is what
was happening in this hacky code branch being removed.
Differential Revision: https://phabricator.services.mozilla.com/D12216
--HG--
extra : moz-landing-system : lando
Previously, the ASR overrides contained Maybe<ClipId>, where Nothing() corresponded to taking the top of the clip/scroll stack instead of overriding. This change removes the associated complexity by ensuring that we always provide the ClipId.
Differential Revision: https://phabricator.services.mozilla.com/D11813
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
If the parent item is removed our assertions will be wrong because
the parent item's bounds will not be added to the invalid rect until
after we've traversed all of the items. Further, the new unbounded rect
for the child item won't be added to the invalid rect unless we do it
ourselves. This makes sure we add the old and new rects to the invalid
rect.
Differential Revision: https://phabricator.services.mozilla.com/D11724
--HG--
extra : moz-landing-system : lando
This makes sure we don't end up with stale entries with geometry clipped
to the previous mImageBounds on the receiving side.
The update code is duplicated for now but will hopefully be cleaned up
after the blob re-coordination work is done.
Differential Revision: https://phabricator.services.mozilla.com/D11566
--HG--
extra : moz-landing-system : lando
This sets a placeholder transform on the root stacking context for the
content display list, and allows us to modify that transform directly in
the compositor. This is similar to what
nsDisplayOwnLayer::CreateWebRenderCommands does for scroll thumb layers,
which are similarly manipulated by APZ for async scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D11180
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
In ClipManager::DefineScrollLayers, we don't always create a scroll ID
for each ASR. We may fail to get the scroll metadata, or it may not be
scrollable, in which case we should use the scroll ID of its ancestor
(or the root scroll ID if there is no ancestor). This should fix a crash
where we simply assumed the leaf of an ASR tree will always have a valid
scroll ID.
Differential Revision: https://phabricator.services.mozilla.com/D10708
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
Animated images will work by changing the external image ID that an
ImageKey points to. We cannot allow the old external image to be
released and potentially unmapped until we have produced a new frame
with the new external image ID. We currently wait until the epoch has
advanced, but in the future when we don't rebuild the scene to animate
an image, the epoch will remain the same. This could cause us to hold
onto no longer used surfaces for much longer than expected. As such, in
this patch we switch to waiting for a FrameRendered notification from
WebRender, which works even if the scene rebuild was avoided.
Differential Revision: https://phabricator.services.mozilla.com/D7500
Animated images will require scheduling a composite of the frame in
addition to updating the ImageKey/external image ID bindings. It would
be good if this could be done as part of the same IPDL message.
Additionally a page may have many animated images that we update the
frame for at the same time, so these updates should be batched together.
In the event that we needed to regenerate the display list, or produce
an empty transaction, ideally we would just throw these resource updates
in with the rest of the changes. This patch allows us to do all of that
without unnecessarily burdening the caller with tracking extra state.
Differential Revision: https://phabricator.services.mozilla.com/D7499
Async animated images need a single ImageKey which can point to any
frame represented by its own external image ID. Additionally a frame
could be referenced again directly (e.g. something shows/uses the first
frame of the animated image).
Before this patch, the ownership between an ImageKey and an external
image ID for a shared surface was not clearly expressed. This resulted
in a special command to release the reference to the external image
separately from deleting the image key.
This patch makes the strong reference to an external image ID and an
ImageKey directly related. Not only does this facilitate multiple
ImageKeys owning the same surface, it also simplifies the ownership
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D7520
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items in a row with different
ASRs. In this case, when we encounter the nested transform item that we
want to defer, we need to flush the previously-deferred transform item
into a WebRenderLayerScrollData item. This patch accomplishes that, and
includes a mochitest that exercises the relevant behaviour.
Depends on D8110
Differential Revision: https://phabricator.services.mozilla.com/D8111
--HG--
extra : moz-landing-system : lando
The implementation of deferred transforms did not handle the case where
we ended up deferring multiple transform items before encountering the
APZ-relevant display item. In this case we need to somehow accumulate
all the deferred transforms. This patch accomplishes that, and includes
a mochitest that exercises the relevant behaviour.
Depends on D8109
Differential Revision: https://phabricator.services.mozilla.com/D8110
--HG--
extra : moz-landing-system : lando
This code will be expanded a bit in the next few patches, so hopefully
the comments here provide a reasonable explanation of what this code is
about.
Differential Revision: https://phabricator.services.mozilla.com/D8108
--HG--
extra : moz-landing-system : lando
On android with webrender enabled, minimising the app results in an
assertion failure: CompositorBridgeParent::DidComposite asserts that
it should not be called with a webrender compositor.
This makes it so that that in CompositorBridgeParent::PauseComposition
we call NotifyPipelineRendered instead of DidComposite for webrender
compositors.
Differential Revision: https://phabricator.services.mozilla.com/D10563
--HG--
extra : moz-landing-system : lando
Similar to bug 1471671, we are seeing missing scroll metadata in cases
we do not expect that, and have been observing low volume crashes in the
wild as a result. It appears that in the non-WR path, it skips such items,
so we should probably do the same thing with WebRender. If it is a real
problem, we will hopefully get a reproducible test case from a user if
scrolling fails for them.
Differential Revision: https://phabricator.services.mozilla.com/D9815
We are seeing crash reports in the wild where there is no scroll
metadata available for an ASR for a display item and its clip. It
appears that in the non-WR path, it skips such items, so we should
probably do the same thing with WebRender. If the scrolling ends up
being wrong, hopefully a reproducible use case will make its way to use
to further debug, as the crash reports have not yielded anything to date.
Differential Revision: https://phabricator.services.mozilla.com/D9699
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
Using layer scaling confuses the filter code (see bug 1497239).
Right now we're sort-of double-scaling. Looks like what the filter code expects
is just getting the scaling passed down, see bug 1224207.
Differential Revision: https://phabricator.services.mozilla.com/D8910
--HG--
extra : moz-landing-system : lando
When a CompositorBridgeParent receives a force first paint message, it
sets the flag on the AsyncCompositionManager, which notifies the
widget code at the next composite via
UiCompositorControllerParent::NotifyFirstPaint().
With webrender, this is crashing as there is no
AsyncCompositionManager. And even if it weren't crashing, the widget
will never receive the first paint message, so it never uncovers its
content.
This change ensures the widget receives the first message when
webrender is enabled. CompositorBridgeParent will set the flag on its
WebRenderBridgeParent, which will set the flag on the next received
display list. When the WebRenderBridgeParent flushes the corresponding
transaction, it calls UiCompositorcontrollerParent::NotifyFirstPaint,
to ensure the widget code gets the message.
Differential Revision: https://phabricator.services.mozilla.com/D9250
--HG--
extra : moz-landing-system : lando
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
--HG--
extra : moz-landing-system : lando
I'll file a followup bug to deal with the fallback transition going wrong.
I don't know why it'd be fine to not apply the scale to SVG wrappers, but on my
quick testing I didn't manage to break it, so I'll spend a bit more time trying
to do that...
Differential Revision: https://phabricator.services.mozilla.com/D8013
--HG--
extra : moz-landing-system : lando
I thought it was going to be trivial to add a test-case for this with a scale
transform and such, but I haven't been able to.
This restores the wallpaper that there was before my change.
Differential Revision: https://phabricator.services.mozilla.com/D8000
--HG--
extra : moz-landing-system : lando
To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
Ciure Andrei
Doug Thayer
Miko Mynttinen
Barret Rennie
sotaro
Sylvestre Ledru
Dorel Luca
Bobby Holley
shindli
Kartikaya Gupta
Ryan Hunt
Alex Gaynor
Jeff Muizelaar
Dzmitry Malyshau
Csoregi Natalia
Chris Peterson
Timothy Nikkel
Noemi Erli
Razvan Maries
Jeff Gilbert
Cosmin Sabou
Markus Stange
Andrew Osmond
Nicolas Silva
Bas Schouten
Lee Salzman
Botond Ballo
Oana Pop Rus
Glenn Watson
Matt Woodrow
Daniel Varga
Emilio Cobos Álvarez
Narcis Beleuzu
Greg Tatum
Brindusan Cristian
Margareta Eliza Balazs
Ehsan Akhgari
Gurzau Raul
Andreea Pavel
WR Updater Bot
Coroiu Cristina
Bogdan Tara
Jonathan Watt
Jeff Muizelaar
Hiroyuki Ikezoe
Jamie Nicol
Ryan VanderMeulen