Currently we try to alternate between light-on-dark and dark-on-light
text rendering masks on macOS depending on text colors. Historically,
this matched earlier versions of macOS reasonably well. In successive
versions of macOS, however, this approximation appears to have broken
down and no longer gives correct results.
Given that recent macOS versions no longer promotes font-smoothing at
all, it seems more reasonable to match Skia's font smoothing handling
because it appears to better work with these more recent versions while
requiring us to have less special code to do so.
Differential Revision: https://phabricator.services.mozilla.com/D229444
Currently we try to alternate between light-on-dark and dark-on-light
text rendering masks on macOS depending on text colors. Historically,
this matched earlier versions of macOS reasonably well. In successive
versions of macOS, however, this approximation appears to have broken
down and no longer gives correct results.
Given that recent macOS versions no longer promotes font-smoothing at
all, it seems more reasonable to match Skia's font smoothing handling
because it appears to better work with these more recent versions while
requiring us to have less special code to do so.
Differential Revision: https://phabricator.services.mozilla.com/D229444
cs_svg_filter_node's fragment shader is effectively one giant switch
statement. Unfortunately the glsl-optimizer pass converts switch
statements in to a dreadful mess of if-elses, and the resulting shader
takes half a minute to compile on some Adreno devices.
As a short term fix, this patch replaces the switch statement with a
series of ifs and else ifs, which are much better than what the
optimizer produces. While this should result in better code on all
GPUs (minus a few where we do not use the optimized shaders), it will
be less efficient for SWGL. As a follow up we should fix the optimizer
to produce better code for switch statements, then revert this change.
Differential Revision: https://phabricator.services.mozilla.com/D229310
No functional change here - but will make it easier to review follow
up patches that call `composite_pass` once per swapchain when using
the `Compositor2` trait.
Differential Revision: https://phabricator.services.mozilla.com/D228558
This is done in order to untangle a borrow-checker knot and make it possible to call it from the closure in ResourceCache::render_as_image.
Differential Revision: https://phabricator.services.mozilla.com/D227371
The logic is similar to the render task cache with important differences:
- If the function is called the tasks are always rendered (no check
whether a previous frame already produced the image).
- Since we want to associate the TextureCacheHandle with an ImageKey,
to render it via a image items, the handle is managed by the resource
cache rather than the render task cache.
Differential Revision: https://phabricator.services.mozilla.com/D227370
Follow up patches will make use of this to store some extra info
related to which swapchain layer should be used for a given tile.
Differential Revision: https://phabricator.services.mozilla.com/D227907
This is done in order to untangle a borrow-checker knot and make it possible to call it from the closure in ResourceCache::render_as_image.
Differential Revision: https://phabricator.services.mozilla.com/D227371
The logic is similar to the render task cache with important differences:
- If the function is called the tasks are always rendered (no check
whether a previous frame already produced the image).
- Since we want to associate the TextureCacheHandle with an ImageKey,
to render it via a image items, the handle is managed by the resource
cache rather than the render task cache.
Differential Revision: https://phabricator.services.mozilla.com/D227370
This is done in order to untangle a borrow-checker knot and make it possible to call it from the closure in ResourceCache::render_as_image.
Differential Revision: https://phabricator.services.mozilla.com/D227371
The logic is similar to the render task cache with important differences:
- If the function is called the tasks are always rendered (no check
whether a previous frame already produced the image).
- Since we want to associate the TextureCacheHandle with an ImageKey,
to render it via a image items, the handle is managed by the resource
cache rather than the render task cache.
Differential Revision: https://phabricator.services.mozilla.com/D227370
This is done in order to untangle a borrow-checker knot and make it possible to call it from the closure in ResourceCache::render_as_image.
Differential Revision: https://phabricator.services.mozilla.com/D227371
The logic is similar to the render task cache with important differences:
- If the function is called the tasks are always rendered (no check
whether a previous frame already produced the image).
- Since we want to associate the TextureCacheHandle with an ImageKey,
to render it via a image items, the handle is managed by the resource
cache rather than the render task cache.
Differential Revision: https://phabricator.services.mozilla.com/D227370
On Xclipse GPUs glGetDebugMessageLog() sometimes returns a larger
count that the count provided as its first argument. This results in
an index out of bounds panic inside gleam's get_debug_messages()
wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D227517
Currently we use glutin's GlRequest::GlThenGles when creating a GL
context. This first attempts to select bind the OpenGL API using
eglBindAPI, falling back to the OpenGL ES API if that fails.
Some Android devices (eg those with Xclipse GPUs) successfully allow
binding the OpenGL API, only for eglChooseConfig to subsequently
return zero available configs. This means using GlThenGles always
results in failure to create a GL context.
To avoid this, this patch makes us specifically request a GLES context
by default on Android. Note that this can still be overridden for
local testing using wrench's --renderer command line argument.
Differential Revision: https://phabricator.services.mozilla.com/D227516
Xclipse GPUs appear render the diagonal linear gradient in this test
case at a slightly different scale than in its reference. This issue
is hardware-specific and unrelated to the bug that the test case is
designed to test.
This patch reworks the test case to use a horizontal linear gradient,
avoiding this issue. The underlying cause will be investigated and
fixed in bug 1928323.
Differential Revision: https://phabricator.services.mozilla.com/D227515
Newer devices often only support aarch64 binaries, and we no longer
run on any 32bit devices in CI, so switch the default build
architecture. Developers will still be able to build arm7 binaries if
required for local testing.
Differential Revision: https://phabricator.services.mozilla.com/D227514
In the most common case (non-cached picture tasks) the specific rect will be skipped in favor of the global clear, however cached picture tasks need a specific clear rect.
Differential Revision: https://phabricator.services.mozilla.com/D226615
This patch moves the clearing code into its own function and attempts to make the logic a bit easier to understand and reason about.
Differential Revision: https://phabricator.services.mozilla.com/D226613
