Bug 1540737 originally used PushLayerWithBlend here but PushLayerWithBlend is
not implemented for D2D. Since then, I believe we've stopped using D2D for
content drawing so it should be possible to switch back to PushLayerWithBlend.
Differential Revision: https://phabricator.services.mozilla.com/D130272
The users of this were removed with FrameLayerBuilder.
Two callers that passed true remained: one was a print
statement, and the other should be fine to change.
Differential Revision: https://phabricator.services.mozilla.com/D128946
I added an option to return also the nodes because it's very helpful for
debugging. A bunch of the "unknown" ones are just elements with
transparent backgrounds (but still hit-testable), so we probably want to
exclude them from the result list or what not to massively reduce the
size of the returned object.
But anyhow, this probably does for a prototype.
Differential Revision: https://phabricator.services.mozilla.com/D128720
This only changes the return value in the case that IsScrollingActive is false but IsMaybeAsynchronouslyScrolled is true. This can only happen if HasDisplayPort is false and HasScrollGrab is false but mZoomableByAPZ is true. mZoomableByAPZ is only true for root content documents. So that means IsAlwaysActive will usually make IsScrollingActive true, except if it overflow hidden and hasn't been scrolled. So the only case this patch will change is the root content document if it hasn't been scrolled and is overflow hidden. In this case I think we do want to treat it as an AGR because it is zoomable, so it is async scrollable (after zooming).
In general we want to move away from IsScrollingActive for async scrolling things. There are only a few callers left, probably only one of them actually wants the concept that IsScrollingActive uses. Once we've removed the other users we can rename it to something like "HasBeenScrolledRecently" or something like that to avoid confusing with active scrolled roots and the use of the word active to mean async scrolling type things.
Differential Revision: https://phabricator.services.mozilla.com/D128362
nsIScrollableFrame::IsScrollingActive basically means "has this scroll frame been scrolled recently or is this the root scroll frame". Neither of which is relevant when we are async scrolling a scrollframe on the compositor.
What determines if we can scroll a scroll frame async is ScrollFrameHelper::mWillBuildScrollableLayer, aka nsIScrollableFrame::IsMaybeAsynchronouslyScrolled.
The code in nsDisplayStickyPosition::GetStickyScrollContainer already mostly neuters nsDisplayStickyPosition is this isn't the case, this just takes it one step further.
This also removes one more user of nsIScrollableFrame::IsScrollingActive, there are only a handful left.
Differential Revision: https://phabricator.services.mozilla.com/D126427
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
GetHighResolutionDisplayPort would return the displayport without the multipler in all situations (pref on or off).
In DisplayPortUtils we are checking the displayport rect before/after setting new displayport margins to see if it changes to determine if we need to invalidate. Since the critical displayport isn't used for anything, the regular displayport is the correct thing to use here.
In nsGfxScrollFrame we are doing a similar thing, except checking that the displayport doesn't change after a scroll.
In nsDisplayListBuilder::OutOfFlowDisplayData::ComputeVisibleRectForFrame it's also the correct thing, as we want to include the same rect for fixed content as we do for non-fixed content. But this is an significant expansion of the dirty rect of fixed content and the code history has fixes related to drawing too much of fixed content and OOMing so a little more scrutiny is reasonable. However if there was a problem with OOM, since this is the same rect we use for non-fixed content we would have OOM problems with regular content, so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D127344
Pushing the clip for the opacity item into the clip manager has a non-trivial cost, so we get better performance if we handle flattening the item before that.
Differential Revision: https://phabricator.services.mozilla.com/D125633
This patch adds plumbing to keep track of why we request frames to be rendered.
This information is then displayed in gecko profile markers on the renderer thread as well as in profiler HUD counters (See "Render reasons" in profiler.rs).
Differential Revision: https://phabricator.services.mozilla.com/D127274
This patch doesn't change any user-observable behavior.
StaticAutoPtr lets us remove a handful of explicit 'delete' statements, by
making deletion happen automatically when these variables are cleared.
Differential Revision: https://phabricator.services.mozilla.com/D127337
Pushing the clip for the opacity item into the clip manager has a non-trivial cost, so we get better performance if we handle flattening the item before that.
Differential Revision: https://phabricator.services.mozilla.com/D125633
For non-WR painting from nsDisplayList::Paint, the display item clip will already be applied to the context, so will still be included in the result via the clip extents.
WebRender fallback painting intentionally doesn't use the clip (since the clip can include the displayport size), to avoid needing to invalidate for display port changes..
Differential Revision: https://phabricator.services.mozilla.com/D125613
The PickDescendant here was never needed for correctness, it only enabled
better layerization on pages with scrolled clips on fixed elements.
With FrameLayerBuilder removed, it doesn't provide any benefits, and it's
causing problems for other container items inside the fixed element,
because some of them accidentally pick up the scrolled ASR instead of the
fixed ASR for themselves.
Differential Revision: https://phabricator.services.mozilla.com/D125496
Text is the exception, where clipping the WR commands to the paint rect can let us reduce the size sent.
We want to avoid this when doing fallback painting, since we don't want to have to track paint rect changes for invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D124589
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
Text is the exception, where clipping the WR commands to the paint rect can let us reduce the size sent.
We want to avoid this when doing fallback painting, since we don't want to have to track paint rect changes for invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D124589
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
Jeff Muizelaar
Sandor Molnar
Andrew Osmond
Emilio Cobos Álvarez
Timothy Nikkel
Butkovits Atila
Marian-Vasile Laza
Matt Woodrow
Nicolas Silva
Tetsuharu Ohzeki
Daniel Holbert
Miko Mynttinen
criss
Botond Ballo