This prevents e.g. navigating the print preview document.
I can try to come up with a test for this, though testing for something
not happening is always a bit more annoying... :)
Depends on D91438
Differential Revision: https://phabricator.services.mozilla.com/D91439
This should make it work on fission, plus is simpler than the
alternative of traversing the whole docshell tree and then undo it.
It also is going to make easier the actual fix for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D91438
There is some complexity in rendering clip masks that contain tiled
images, when the transform is complex (getting edge AA correct etc).
To work around this, the existing implementation simply draws the
entire primitive region with each image tile of the clip mask. This
works but is slow on large clip masks.
We can apply a simple optimization when the clip is axis-aligned,
which is the common case for the vast majority of pages. When this
case occurs, calculate a device space sub-rect for each of the
image mask tiles, and only draw to that part of the clip mask.
This can drastically reduce the amount of overdraw on pages that
have tiled clip masks that take up a large portion of the screen.
In the long term, WR should handle the case of complex transform
+ tiled clip masks better too.
Differential Revision: https://phabricator.services.mozilla.com/D91540
There is some complexity in rendering clip masks that contain tiled
images, when the transform is complex (getting edge AA correct etc).
To work around this, the existing implementation simply draws the
entire primitive region with each image tile of the clip mask. This
works but is slow on large clip masks.
We can apply a simple optimization when the clip is axis-aligned,
which is the common case for the vast majority of pages. When this
case occurs, calculate a device space sub-rect for each of the
image mask tiles, and only draw to that part of the clip mask.
This can drastically reduce the amount of overdraw on pages that
have tiled clip masks that take up a large portion of the screen.
In the long term, WR should handle the case of complex transform
+ tiled clip masks better too.
Differential Revision: https://phabricator.services.mozilla.com/D91540
As with nsRegion, nsIntRegion has an implicit constructor for IntRect and so
some dangling Stringify(IntRect) sites also get converted here.
Depends on D91525
Differential Revision: https://phabricator.services.mozilla.com/D91526
Apparently a bunch of Stringify(nsRect) sites were getting converted to
Stringify(nsRegion(nsRect)) due to the the nsRegion implicit constructor, so
this updates those too.
Depends on D91524
Differential Revision: https://phabricator.services.mozilla.com/D91525
If deleting/replacing range selects a text node, it may shrink the range
to start and end of the text node. So, the result may not be wider than
the original range.
This behavior is compatible with Blink.
Depends on D90639
Differential Revision: https://phabricator.services.mozilla.com/D90640
Previously, there was typically a large difference between the
number of primitives in the display list and the number of prims
that were considered visible. However, the Gecko display port
ensures that this is not the case. Additionally, the size of
the instance structure was previously sensitive to performance,
as they were copied during picture cache slice creation, but this
is no longer the case.
As part of the work to retain more state between frames and scenes,
keep the prim visibility information embedded inside the instance
rather than creating and storing it per frame in the prim scratch
buffer.
This shows up as a performance win in talos, and simplifies some
of the code that interacts with this. Follow up patches will
remove the existence of some of these fields, which are doing
duplicate / redundant work.
Differential Revision: https://phabricator.services.mozilla.com/D91360
Previously, there was typically a large difference between the
number of primitives in the display list and the number of prims
that were considered visible. However, the Gecko display port
ensures that this is not the case. Additionally, the size of
the instance structure was previously sensitive to performance,
as they were copied during picture cache slice creation, but this
is no longer the case.
As part of the work to retain more state between frames and scenes,
keep the prim visibility information embedded inside the instance
rather than creating and storing it per frame in the prim scratch
buffer.
This shows up as a performance win in talos, and simplifies some
of the code that interacts with this. Follow up patches will
remove the existence of some of these fields, which are doing
duplicate / redundant work.
Differential Revision: https://phabricator.services.mozilla.com/D91360
Turns curveType into a enum. The change is mostly mechanical fixing of
the the code to the new structure except that for Parametrics curves
we now store the result of COUNT_TO_LENGTH as the len.
This mostly affects compute_curve_gamma_table_type_parametric where we
use the post COUNT_TO_LENGTH instead of the pre COUNT_TO_LENGTH.
Differential Revision: https://phabricator.services.mozilla.com/D91421
Previously, dirty rect regions would only be created for tiles
with a texture surface. This means that slices where the tile is
handled by a background color only would not include that in the
dirty rect area.
This is required for a follow up optimization that will rely on
this dirty rect region for primitive visibility determination, but
it may also have shown up as a visible bug on platforms that
support partial present.
Differential Revision: https://phabricator.services.mozilla.com/D91384
The getConstructorName testing function and UbiNode got the constructor name of a
JS object via the ObjectGroup's TypeNewScript. There's currently no way to get that
information without TI (and it always depended on brittle optimization heuristics)
so this patch removes that code.
Differential Revision: https://phabricator.services.mozilla.com/D91419
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
Frederic Wang
Christoph Kerschbaumer
Sebastian Hengst
Emilio Cobos Álvarez
Jan-Erik Rediger
pctopgs
Glenn Watson
Mirko Brodesser
Narcis Beleuzu
Matt Woodrow
Kartikaya Gupta
Masayuki Nakano
Jeff Muizelaar
Noemi Erli
Dale Harvey
Jan de Mooij
Jim Mathies
Tooru Fujisawa
Butkovits Atila
Timothy Nikkel
Zibi Braniecki