This addresses some deficiencies in the way solid spans are handled when clip-masking
or AA is used. In that case, the overhead of the extra blend stage is significant and
we can do a better just by temporarily disabling the those parts of the blend stage
and fast-pathing them instead of just going through commit_solid_span.
Differential Revision: https://phabricator.services.mozilla.com/D104963
Now that most of the complicated alpha-pass features such as clip-masking and anti-aliasing
are handled in SWGL during the blend stage, most of the fast-paths are identical and only call
swgl_commitTextureLinear in a tight loop. We can do a lot better here by just moving that loop
into SWGL, not only making it faster but removing all the redundant boiler-plate code out of
the shaders.
Differential Revision: https://phabricator.services.mozilla.com/D104536
Now that most of the complicated alpha-pass features such as clip-masking and anti-aliasing
are handled in SWGL during the blend stage, most of the fast-paths are identical and only call
swgl_commitTextureLinear in a tight loop. We can do a lot better here by just moving that loop
into SWGL, not only making it faster but removing all the redundant boiler-plate code out of
the shaders.
Differential Revision: https://phabricator.services.mozilla.com/D104536
This makes -moz-outline-radius a no-op, but keep it for now.
If/when we make this the default in release, we can remove it.
Differential Revision: https://phabricator.services.mozilla.com/D104324
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
To accurately test the condition we need to tweak a transform every 74 ms. This leads to problems on platforms that can't complete a full paint cycle through the reftest harness (which consists of two paints, the one for the screen and then one to update the reftest canvas). This only used to affect android debug builds severely but seems to have gotten worse on linux debug and asan builds.
Differential Revision: https://phabricator.services.mozilla.com/D103738
This patch improves nsCanvasFrame::Reflow in a few ways.
First, we now iterate over mFrames and reflow every child.
This makes it more robust vis-à-vis the order of any placeholders
and the root frame, and also resilient against a missing root
frame (this fixes the fatal assertion in this bug). We now
also actually reflow all placeholders which wasn't the case
before. It seems like a prudent thing to do.
I also added a separate nsReflowStatus for each child.
We now also call SetOverflowAreasToDesiredBounds() in all
cases. We failed to do that in the 'mFrames.IsEmpty()' case
before, which triggered the assertions in bug 1655630 and
bug 1392106.
Differential Revision: https://phabricator.services.mozilla.com/D103592
Once all the remaining patches for test tweaks / fixes have landed, this
patch should be green on try. Couple test annotation changes:
* clip-003.html fails the same way it fails on mac (odd, but couldn't
repro...). I'll try to dig a bit more before calling it a day.
* radiobutton-min-size starts behaving like every other platform.
* Event-dispatch-redispatch and baseline-alignment-and-overflow start
passing.
* Couple minor fuzzy annotations (one was backwards, the other was
missing).
Differential Revision: https://phabricator.services.mozilla.com/D103327
The non-native theme does two things which, combined, cause this test to
fail.
The first one is that it has slightly bigger checkboxes than other
themes (14px vs. 13px).
The second one is that it has a 2px widget-imposed border, like Mac:
https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/widget/nsNativeBasicTheme.cpp#1367-1369
Which causes its baseline to go down by that amount. This was done
intentionally in bug 1675389, though I guess it could be reconsidered.
These two things combined make the checkbox grow the line slightly in
this test-case, causing the elements to move 1px apart.
The test is intended to check that the baseline calculation of a
checkbox/radio is correct, which it is, so prevent that undesired side
effect by resetting the margin to zero.
Differential Revision: https://phabricator.services.mozilla.com/D103324
With non-native theme, number inputs have zero padding-inline-end by
default, so otherwise the test would fail by a few pixels.
Differential Revision: https://phabricator.services.mozilla.com/D103246
This doesn't change behavior by default but allows authors to remove the
padding if they wish to.
I thought this was going to be problematic because of the windows
arrowbutton, but that doesn't respect select padding so we're good.
Differential Revision: https://phabricator.services.mozilla.com/D103245
Combobox select has the block-axis padding in the comboboxcontrol frame.
Moving it fixes bug 1560824 and should be better, so will do that there.
1px block axis padding on buttons matches Chrome too, so shouldn't be a
problem compat-wise.
Differential Revision: https://phabricator.services.mozilla.com/D103244
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
I'm using "/^Windows\x20NT\x206\.1/.test(http.oscpu)" to check for Windows 7,
which I found (with Win7-related code comments) elsewhere in reftest.list
files.
I'm replacing a "fuzzy-if(!nativeThemePref,...)" annotation here, which I think
was simply mis-applied here -- this test doesn't have any form controls or
theme-related stuff, so it doesn't make sense that its rendering would be
theme-dependent. I suspect this annotation was added by mistake, due to this
test intermittently failing by coincidence on a try run where the
!nativeThemePref configuration was being tested.
Differential Revision: https://phabricator.services.mozilla.com/D103083
This matches other browsers, and the default themed textareas on Windows
too.
To be landed after the soft freeze, just in case, of course.
Differential Revision: https://phabricator.services.mozilla.com/D102843
This matches other browsers, and the default themed textareas on Windows
too.
To be landed after the soft freeze, just in case, of course.
Differential Revision: https://phabricator.services.mozilla.com/D102843
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
This allows us to default to skipping the bundled Twemoji Mozilla font when running on Win8.1 or later,
where we can assume Segoe UI Emoji is available.
The new pref here replaces the existing pair of boolean prefs that were only supported on Android,
and is now respected on all platforms. Available settings are:
0 disable use of app-bundled fonts
> 0 enable use of app-bundled fonts
< 0 default (auto): decide at startup, based on the system environment
(The pref is relevant only at startup; changing its value during a session will not make the bundled fonts
appear/disappear dynamically.)
Differential Revision: https://phabricator.services.mozilla.com/D102085
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
Also disable for users with 64-bit Firefox with 1-2 cores, and less than
2 GB of physical memory. It was already disabled for 32-bit Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D101052
This test spams the same assertion either 4 or 6 times, with this variation
probably being due to an extra reflow which we sometimes incur due to a
font-fallback task having coincidentally just completed, as described in
https://groups.google.com/g/mozilla.dev.platform/c/VBh6oLm4EbQ/m/dbaJcAe6BgAJ
Previously the test was annotated as asserting exactly 4 times, but now we
need to allow for it to sometimes assert 6 times instead.
Differential Revision: https://phabricator.services.mozilla.com/D101506
This is a minor adjustment to the font-selection heuristics implemented in bug 1371386:
for emoji codepoints, we should accept the font(s) specified in the font.name-list.emoji
preference even if it's a monochrome font for characters that would normally be expected
to use a color rendering, as this is the user's choice.
Differential Revision: https://phabricator.services.mozilla.com/D101162
This test spams the same assertion either 4 or 6 times, with this variation
probably being due to an extra reflow which we sometimes incur due to a
font-fallback task having coincidentally just completed, as described in
https://groups.google.com/g/mozilla.dev.platform/c/VBh6oLm4EbQ/m/dbaJcAe6BgAJ
Previously the test was annotated as asserting exactly 4 times, but now we
need to allow for it to sometimes assert 6 times instead.
Differential Revision: https://phabricator.services.mozilla.com/D101100
Resetting focus would also clear selection on editable element, so get
current selected text before moving focus to findbar to make
prefill-with-selection work if the content is loaded in chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D89557
Mainly this implements a new set of SWGL intrinsics based around swgl_allowTextureNearest
and swgl_commitTextureNearest which can fairly easily provide a further fast-path above
and beyond swgl_commitTextureLinear. This requires the row be from an axis-aligned 1:1
draw so that we can do something not unlike a fast copy of the texture data straight
to the destination in cases where even the linear filter would be essentially doing
the same thing in a more expensive way. For now, only a few WR shaders that were already
using swgl_commitTextureLinear have been fast-pathed with the new intrinsics to see if
this provides significant performance benefit.
Differential Revision: https://phabricator.services.mozilla.com/D100079
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
Bug 1682398 caused us to layerize mixed-blend-mode less aggressively
which means that we're using Skia everywhere for these tests now
instead of relying on the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D99896
Resetting focus would also clear selection on editable element, so get
current selected text before moving focus to findbar to make
prefill-with-selection work if the content is loaded in chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D89557
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
We unshipped these a while ago and left the pref just for testing
purposes. But now all the reftests using it were conveniently migrated
to chrome:// tests, so we no longer need it.
Differential Revision: https://phabricator.services.mozilla.com/D56950
The textcase and reference differ by a single space.
We should check that we've not run off the end of the path while we're skipping characters
Also removes a redundant check presumably left over from some earlier refactoring.
Differential Revision: https://phabricator.services.mozilla.com/D97828
The textcase and reference differ by a single space.
We should check for new clusters or ligature groups in textPaths even in skipped characters
Also removes a redundant check presumably left over from some earlier refactoring.
Differential Revision: https://phabricator.services.mozilla.com/D97828
The flex container fragment's tentative block-size can be different from
its final size if there is any unbreakable child that has a block-size
larger than the available block-size. The two passed reftests are such
examples.
Differential Revision: https://phabricator.services.mozilla.com/D97522
If the flex container frame's tentative border-box size is different
from its final size, and it's in vertical-rl writing mode, we need to
adjust children's position. This is implemented in Part 3.
Differential Revision: https://phabricator.services.mozilla.com/D97521
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
The flex container fragment's tentative block-size can be different from
its final size if there is any unbreakable child that has a block-size
larger than the available block-size. The two passed reftests are such
examples.
Differential Revision: https://phabricator.services.mozilla.com/D97522
If the flex container frame's tentative border-box size is different
from its final size, and it's in vertical-rl writing mode, we need to
adjust children's position. This is implemented in Part 3.
Differential Revision: https://phabricator.services.mozilla.com/D97521
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
The original code doesn't work for "writing-mode:vertical-rl" because
its block flow direction is the opposite of "writing-mode:vertical-lr."
Differential Revision: https://phabricator.services.mozilla.com/D96786
Changing the size or number of layers of textures unfortunately usually leads to small sampling differences which requires fixing in the refetest references.
Differential Revision: https://phabricator.services.mozilla.com/D95680
First, copy the "vertical-lr" reftests added in Part 3, then running the
following command to convert to `writing-mode: vertical-rl` for all the
reftests.
```
rg -l "vertical-lr" flexbox-*vertical-rl* | xargs sed -i "s/vertical-lr/vertical-rl/g"
```
reftest.list are modified manually.
Differential Revision: https://phabricator.services.mozilla.com/D96742
First, copy the original reftests, then running the following command to
add `writing-mode: vertical-lr` to all the reftests, and modify `<link>`
tag.
```
function rename () {
rg -l "$1" flexbox-*vertical-lr* | xargs sed -i "s/$1/$2/g"
}
rename "<style>" "<style>\n html \{\n writing-mode: vertical-lr;\n \}"
rename "single-column" "single-column-vertical-lr"
rename "multi-column" "multi-column-vertical-lr"
rename "single-row" "single-row-vertical-lr"
rename "multi-row" "multi-row-vertical-lr"
```
reftest.list are modified manually.
Differential Revision: https://phabricator.services.mozilla.com/D96741
Changing the size or number of layers of textures unfortunately usually leads to small sampling differences which requires fixing in the refetest references.
Differential Revision: https://phabricator.services.mozilla.com/D95680
There appears to be a substantial overhead for trying to wake cold threads
from a thread pool (especially with rayon), so for now let's leave the existing
thread spawning in place, but reduce the stack size for individual threads.
Since these threads only call into SWGL's composite routines and do little else,
there isn't much harm in having a small stack size.
Differential Revision: https://phabricator.services.mozilla.com/D96748
... which is an array of pairs of ranges, and use it instead of the
existing printRange / startPage / endPage settings.
Differential Revision: https://phabricator.services.mozilla.com/D96093
Changing the size or number of layers of textures unfortunately usually leads to small sampling differences which requires fixing in the refetest references.
Differential Revision: https://phabricator.services.mozilla.com/D95680
This affects a few of the examples in the text/white-space-2 reftest, but the changes look sensible;
more significantly from an interop point of view, there are specific web-platform reftests that are
currently failing, but will pass after the patch.
Differential Revision: https://phabricator.services.mozilla.com/D95811