Previously, we would do a fine-grained visibility check for
prims against the dirty rect stack (after coarse grained
tile visibility), then prepare the primitive, then determine
which command buffer(s) the prim should be added to, based
on which tile(s) the prim affects.
The patch changes this so that the fine-grained visibility
check returns a list of command buffer(s) that the prim
should be added to. This is passed to the prim prepare
step, and then used to directly add prims to the buffers
rather than checking which tiles are affected by the prim.
The motivation for doing this will become apparent in
follow up patches. We want to be able to encode
multiple command buffer commands per-prim, whereas it
was previously only possible to encode primitive
commands. By allowing prim-prepare to write directly
to the command buffers, rather than return a list of
primitive commands, we can write whatever commands
are needed. Future patches will use this to write
segment rect streams, and other information.
A side effect of this is that the `tile_rect` field
in the `PrimitiveVisibility` struct is no longer
required. This reduces the size of `PrimitiveInstance`
from 104 bytes to 88 bytes, which is likely to be
a reasonable performance win on pages that have
high primitive counts.
Differential Revision: https://phabricator.services.mozilla.com/D172081
The head files import NetUtil already, additionally, most of these don't actually do anything because they are not assigned
Differential Revision: https://phabricator.services.mozilla.com/D172943
el -> 0894acdd52c4c3fe9cefb85450974b0bfd82fbd0
lo -> 1e08bf1751b34d76194c659cf193820950ab45a2
my -> 83ed2c486c56c9631490d9caa4018294277513fb
sk -> b0925be36ca5039a12d29eb9e85d1a41b4625718
skr -> 1381a18c12a3e9eda83bffa74ae678afda877afc
sr -> ca40f6c6abb7093e41d642e24e77a39c94245e85
zh-CN -> 4a41931c7ed4928b0350a81d84d781d7cec9b7c0
In the patches for bug 1823215, we eliminated the use of a local copy of the glyph runs array
during SortGlyphRuns; but we call RemoveElementAt individually for each run to be coalesced,
which means potentially moving all the rest of the array multiple times. Instrumentation shows
that we sometimes end up with dozens of glyphruns to be coalesced (or even hundreds/thousands,
in pathological cases), which becomes quite inefficient.
Using RemoveElementsBy(predicate) instead will minimize the copying/moving of the remaining
array elements.
Differential Revision: https://phabricator.services.mozilla.com/D172945
Rulesets are atomic units. It does not select an arbitrary subset as an
"error recovery mechanism". This commits switches to the common quota
verification logic from the previous commit (RuleQuotaCounter).
Differential Revision: https://phabricator.services.mozilla.com/D172251
As a preparation for quota enforcement for session rules and dynamic
rules, this refactors the quota enforcement, by introducing a single
helper (RuleQuotaCounter) that keeps track of the rule counts and
is responsible for enforcing quotas.
This patch is purely a refactor, and the only behavioral changes are the
strings in error messages.
The error messages of static rules were previously not covered by unit
tests; this patch also improves test coverage in that area.
Lastly, removed TODO from the static rule loading. When a static ruleset
were to exceed the quota, the desired behavior is to ignore it and try
the next ruleset (this is consistent with Chromium).
Differential Revision: https://phabricator.services.mozilla.com/D172250
The math for directly calculating the endpoint of the arc is actually trivial,
and ArcToBezier is pretty expensive so should be avoided.
Differential Revision: https://phabricator.services.mozilla.com/D172929
The standard WPT viewport is 800px wide, which (as a multiple of 100) can
conveniently resolve whole-number percentages without creating a fractional
size. But the default body-margins reduce it by 16px, to 784, which is less of
a round-number percent basis.
This was producing some fractional-pixel sizes in this test, which were causing
a fuzzy failure, due to antialiasing differences between how "width" and
"clip-path" handle fractional pixel sizes.
So, this patch just removes those margins, to give us 800px as our percent
basis, which avoids fractional-pixel sizes in this test.
Similarly: this patch also makes us use the Ahem font so that the test's "ex"
units will resolve to a predictable value, instead of whatever
potentially-fractional-value the default font would yield.
Differential Revision: https://phabricator.services.mozilla.com/D172917
See https://bugzilla.mozilla.org/show_bug.cgi?id=1821793#c2 for more info on
these failures.
In most cases here, I'm taking the fuzzy annotations from the exact values that
wpt.fyi reports for Firefox/Gecko. The only exception is for
clip-path-borderBox-1a.html, where I use a (higher) threshold taken from the
values that wpt.fyi reports for Safari/WebKit (which has a similar fuzzy
failure).
Differential Revision: https://phabricator.services.mozilla.com/D172916
Two issues:
* The part="content" of this popup is the <slot> itself. As such, it
now respects box-sizing, which our existing rules didn't account for.
* The <slot> didn't automatically fill the popup as old XUL did.
Explicitly set width/height.
Differential Revision: https://phabricator.services.mozilla.com/D172888
This patch makes the SearchInput a connected component, This allows us cleanup
all the seperate actions and reducer logic and makes it easier to add new SearchInput
with modifers functionality.
Differential Revision: https://phabricator.services.mozilla.com/D171034
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
While Firefox builds for Android ARMv7 don't support non-NEON
processors, downstreams (including non-Android ones) may still want to
support them.
On the Firefox builds that don't support non-NEON processors, the NEON
flags are actually already passed globally, and they don't need to be
explicitly added. NEON_FLAGS is actually only meant to be used for
sources that specifically need NEON support even when the target doesn't
support it, for, e.g. specialized code behind runtime CPU detection.
So removing NEON_FLAGS is a no-op in practice when NEON processors are
already targeted.
Differential Revision: https://phabricator.services.mozilla.com/D172801
bg -> 01360f4bce126fd0758abb5759e8d88c809acd25
da -> b4c0357e5185526ae35a036310908bae02e97add
fr -> d95fa0593e2d0f5be54d2e5ab375ba85b39d4ba1
gn -> 6afafc4c9de1141ae87e63fe89e307e877f5b2c9
he -> 103f251af0aaee41278d9cc08085b431328562fa
hu -> d50652202be850d4e8df9d894828132059553835
ia -> ccf08deaa498f3e2491d7755f09651d3dae63bf5
is -> db0d33fcbe9a063a30ac28da1cd77f88a2218ec4
zh-CN -> 9ba36aef7f4fedbacc712c24ad4064b9565b6825