We used to do this before bug 1860328 (see also bug 1547802, which
introduced this wallpaper).
Keep doing it, but teach it to deal with multiple carets. I don't want
to keep chasing caret invalidation issues, and it's probably not worth
the time given we almost always paint 0 or 1 caret.
Differential Revision: https://phabricator.services.mozilla.com/D206257
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
The caret position is in the DOM, and sometimes can get out of sync.
While that is an issue, it's not new: The code before the regressing bug
papered over it on a pre-pass before entering DL building.
Instead, deal with it using MarkFramesForDisplay (just like we mark the
caret frame itself, which has the same issue), and invalidate the old
frame more precisely by tracking it in nsCaret directly.
Also, add missing invalidation in PresShell::SetCaret, where the caret
might change and the old caret might not be invalidated properly.
Differential Revision: https://phabricator.services.mozilla.com/D205369
The only useful thing it does is to draw the inner focus ring (which is
windows-and-chrome-only, for what is worth).
The rest can be covered by more generic code-paths. In particular
shadows / backgrounds already work properly even with themed frames via
DisplayBorderBackgroundOutline.
Differential Revision: https://phabricator.services.mozilla.com/D203114
Generally, we mark a caret frame for display first, and then
nsCaret tracks this frame in nsCaret::SchedulePaint to call
MarkNeedsDisplayItemRebuild() accordingly. However, it's possible
for nsCaret::SchedulePaint fails to find the caret frame (i.e, selection changes),
so we end up not calling MarkNeedsDisplayItemRebuild() on this frame.
This patch improves this case by manually setting this caret frame
to nsCaret, so that it's always tracked.
Differential Revision: https://phabricator.services.mozilla.com/D200880
In order to create less WebRenderLayerScrollData currently we use a deferred transform item
https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82
We don't need a WebRenderLayerScrollData for every transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.
However this optimization can lead to us creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.
WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.
This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.
I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.
Differential Revision: https://phabricator.services.mozilla.com/D197446
The bug comes about because the svg transform is changed, so IncrementScaleRestyleCountIfNeeded gets called. It determines that there is no transform because it doesn't check svg transforms, so it incorrectly concludes that there was a transform but now it was removed, and so marks the scale as having been changed. Then in ChooseScale in StackingContextHelper, because we think the scale is being animated, we clamp the allowed scale factor based on the ratio of the viewport and the size of the svg. So avoiding marking this as incorrectly having an animating scale fixes the bug.
A simpler fix for this bug would be to check if the mPreviousTransformScale was Nothing() and only marked as mutated if it was Some.
This fix is a bit more complicated but it allows us to detect svg transform scales changing.
Differential Revision: https://phabricator.services.mozilla.com/D200579
Generally, we mark a caret frame for display first, and then
nsCaret tracks this frame in nsCaret::SchedulePaint to call
MarkNeedsDisplayItemRebuild() accordingly. However, it's possible
for nsCaret::SchedulePaint fails to find the caret frame (i.e, selection changes),
so we end up not calling MarkNeedsDisplayItemRebuild() on this frame.
This patch improves this case by manually setting this caret frame
to nsCaret, so that it's always tracked.
Differential Revision: https://phabricator.services.mozilla.com/D200880
Generally, we mark a caret frame for display first, and then
nsCaret tracks this frame in nsCaret::SchedulePaint to call
MarkNeedsDisplayItemRebuild() accordingly. However, it's possible
for nsCaret::SchedulePaint fails to find the caret frame (i.e, selection changes),
so we end up not calling MarkNeedsDisplayItemRebuild() on this frame.
This patch improves this case by manually setting this caret frame
to nsCaret, so that it's always tracked.
Differential Revision: https://phabricator.services.mozilla.com/D200880
GVST is how these probes sent data in Fenix and is now unnecessary (and doesn't send data in Fenix release) since Firefox Desktop has direct access to Glean. We therefore need to clean them up in some capacity.
Following the recommendations from the GeckoView Streaming (GVST) validation effort, this is a pure Glean api implementation of the metrics that fell under gfx and its subcategories in geckoview streaming.
Each metric retains its previous name, and gains a Glean Interface for FireFox Telemetry (GIFFT) version, such that downstream data analyses will not be impacted.
Differential Revision: https://phabricator.services.mozilla.com/D198872
It will get initialized to nothing if we do create a new object here, but if we use a cached asr we shouldn't clear the view id because the view id for a frame can't change.
Differential Revision: https://phabricator.services.mozilla.com/D199712
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
Fixed and Sticky position side bits should only be necessary for fixed
or sticky position items that are fixed or stuck to the root content. As
a result, there is no need to add the fixed or sticky position hit test
info to items that are not.
Differential Revision: https://phabricator.services.mozilla.com/D192272
Fixed and Sticky position side bits should only be necessary for fixed
or sticky position items that are fixed or stuck to the root content. As
a result, there is no need to add the fixed or sticky position hit test
info to items that are not.
Differential Revision: https://phabricator.services.mozilla.com/D192272
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
Fixed and Sticky position side bits should only be necessary for fixed
or sticky position items that are fixed or stuck to the root content. As
a result, there is no need to add the fixed or sticky position hit test
info to items that are not.
Differential Revision: https://phabricator.services.mozilla.com/D192272
