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 cleans up the WR brush shaders to not have to use its own
implementation of init_transform_fs() for anti-aliasing when SWGL
is available. To enable this, most of the details of AAing have
been moved into brush.glsl to simplify the control knobs and
allow easier modifications.
With swgl_antiAlias() used, the drawSpan fast-paths no longer have to
care about whether ot not AA is enabled, so we can more easily stay
on these fast-paths without worry.
Differential Revision: https://phabricator.services.mozilla.com/D104493
The main goal of this patch is to move all the complexity of optionally
handling anti-aliasing out of the GLSL drawSpan fast-paths and into SWGL
itself into specific blend-mode handling of anti-aliasing. Mainly this
adds a swgl_antiAlias() extension to be called from the GLSL vertex shader,
after which no further involvement is necessary from the shader to work.
This also enables SWGL to better track those areas of a span that don't
need any anti-aliasing applied, and so can potentially be faster.
Some massaging of blend_pixels() was necessary to get it to inline properly
with all the extra cases added. This is mainly a consequence of the DO_AA
macro that lives inside BLEND_CASE, which is used to handle the dispatching
of new AA_BLEND_KEY and AA_MASK_BLEND_KEY cases. The parameters for these
AA modes are mostly handled in SWGL via the aa_span() function, which computes
the area of the span where non-opaque AA weights are necessary and where it can
skip over the opaque interior.
There are some incidental drive-by cleanups that were necessary of bvecs and
pack_pixels.
Differential Revision: https://phabricator.services.mozilla.com/D104492
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 cleans up the WR brush shaders to not have to use its own
implementation of init_transform_fs() for anti-aliasing when SWGL
is available. To enable this, most of the details of AAing have
been moved into brush.glsl to simplify the control knobs and
allow easier modifications.
With swgl_antiAlias() used, the drawSpan fast-paths no longer have to
care about whether ot not AA is enabled, so we can more easily stay
on these fast-paths without worry.
Differential Revision: https://phabricator.services.mozilla.com/D104493
The main goal of this patch is to move all the complexity of optionally
handling anti-aliasing out of the GLSL drawSpan fast-paths and into SWGL
itself into specific blend-mode handling of anti-aliasing. Mainly this
adds a swgl_antiAlias() extension to be called from the GLSL vertex shader,
after which no further involvement is necessary from the shader to work.
This also enables SWGL to better track those areas of a span that don't
need any anti-aliasing applied, and so can potentially be faster.
Some massaging of blend_pixels() was necessary to get it to inline properly
with all the extra cases added. This is mainly a consequence of the DO_AA
macro that lives inside BLEND_CASE, which is used to handle the dispatching
of new AA_BLEND_KEY and AA_MASK_BLEND_KEY cases. The parameters for these
AA modes are mostly handled in SWGL via the aa_span() function, which computes
the area of the span where non-opaque AA weights are necessary and where it can
skip over the opaque interior.
There are some incidental drive-by cleanups that were necessary of bvecs and
pack_pixels.
Differential Revision: https://phabricator.services.mozilla.com/D104492
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
In order to hit the fast path in ANGLE for readback from the
DirectComposition surface tiles, we need to ensure it uses
the same format as intermediate surfaces we are reading back to.
DirectComposition docs claim that both RGBA8 and BGRA8 formats
are supported for surfaces, and doesn't mention any performance
concerns.
I did some basic testing on an NVIDIA GTX 1050 and an Intel
HD530 and didn't notice any performance difference in Gecko
or in DWM.
This patch lands just the format change, so we can easily detect
any correctness or performance issues from the format change.
Differential Revision: https://phabricator.services.mozilla.com/D104771
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
We don't actually need to use brush_mix_blend or KHR_blend_equation_advanced for multiply, screen,
and exclusion modes. Screen and exclusion can be done with simple blending, and multiply can be
done with dual-source blending. Since multiply is the most common mix-blend mode, and dual-source
blending is also common on the desktop with our ANGLE driver, this should be a significant boost
for mix-blend-mode performance for us across.
Differential Revision: https://phabricator.services.mozilla.com/D104614
Due to rendering issues reported on a Mali-T628 and Mali-T760, disable
partial present on all Mali-T6xx and T7xx devices. We know that not
all T6xx and T7xx devices are affected, so this is being cautious. The
driver version is probably more important than the GPU model. We
should make the block more precise once more is known about the bug.
Differential Revision: https://phabricator.services.mozilla.com/D104678
This makes form controls match the rest of the GTK theme like selection
colors, etc.
An alternative to this would be to just use non-native colors on GTK for
all content, but that seems somewhat unfortunate and we do the right
thing for scrollbars so...
I've tried on a variety of themes and this looks nice so far.
Differential Revision: https://phabricator.services.mozilla.com/D104496
This is an alternate approach to aadbc6deca05.
CTFontCreateWithGraphicsFont seems to give "LastResort" when used on a
system CGFont with variation applied on 10.12-10.14. We can avoid that
by using CTFontCreateWithGraphicsFont with a variation descriptor.
I'm only applying this approach to cairo for now to mimimize the risk
of this breaking something or causing the crashes that we were seeing
before.
See https://github.com/servo/core-foundation-rs/pull/439 for
a standalone test case.
Differential Revision: https://phabricator.services.mozilla.com/D104581
If we have more than 8 unused/reusable staging textures and buffers for more than 120 consecutive frames, start deallocation them, spreading the deallocation over multiple frames.
The vast majority of frames require less than 4 staging textures and buffers (most don't require any), but some SVG animations can put a lot of pressure on uploads, requiring 30+ staging textures per frame. This patch avoids staying at this kind of peak memory usage for too long.
Differential Revision: https://phabricator.services.mozilla.com/D104510
Instead of using a triple buffering scheme, tag each texture with a frame index and only reuse a texture that hasn't been used for more than two frames.
Differential Revision: https://phabricator.services.mozilla.com/D104421