There is some edge AA fuzziness due to the differences between
the test and reference. Fuzzing them doesn't affect the test
result as when the bug occurs the rendering difference is
dramatically different.
Differential Revision: https://phabricator.services.mozilla.com/D168306
Reverts an optimization that can cause artifacts on some pages. We
need to do a deeper investigation at some point to find out why,
and then reenable the optimization.
Differential Revision: https://phabricator.services.mozilla.com/D168026
Revert the original changes from bug 1772049 for now. We don't
currently rely on that patch, having found a simpler way to
handle how that code interacts with the backdrop-filter code.
Differential Revision: https://phabricator.services.mozilla.com/D168015
This removes the capability of having differently-sized vertical and
horizontal scrollbars (which is only potentially used in windows, and in
practice almost-never used). For that case, we choose the larger of
vertical/horizontal scrollbar sizes.
This is in order to be able to realistically expose the scrollbar size
to CSS, see blocked bug.
We make RecomputeScrollbarParams the central place where each scrollbar
style decides its sizes, and make GetDPIRatioForScrollbarPart handle the
cocoa special-case of scaling to 1 or 2, but nothing else.
Differential Revision: https://phabricator.services.mozilla.com/D168080
Skia upstream removed deprecated clip ops that could be used to replace
the clipping stack and bypass clips. We shouldn't really need to do this
anymore, as we can work around it just using public APIs.
The only SkCanvas operation that allows us to bypass clipping is
writePixels, which still allows us to implement CopySurface/putImageData.
Other instances where we were using the replace op for DrawTargetWebgl
layering support can just be worked around by creating a separate
DrawTargetSkia pointing to the same pixel data, but on which no clipping
or transforms are applied so that we can freely do drawing operations
on it to the base layer pixel data regardless of any user-applied clipping.
Differential Revision: https://phabricator.services.mozilla.com/D168039
Modify AHardwareBuffer implementation as to support gl::SharedSurface of out-of-process WebGL. And remove unused AHardwareBuffer implementation.
By limiting AHardwareBuffer only in GPU process, AHardwareBuffer implementation becomes simpler. We do not need to handle cross process AHardwareBuffer delivery and cross process android Fence delivery.
Differential Revision: https://phabricator.services.mozilla.com/D167911
Some widely-used icon fonts use ligature rules to replace icon names such as "volume_up"
or "down_arrow" with icon glyphs. If the site is designed to use such a font, but the user
disables document fonts and we use our default Latin font instead, the underlying text will
be rendered instead of the intended icon.
To enable such fonts to continue to work, we provide a list of known ligature-icon fonts
and allow them to be used even when the document-fonts setting is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D167923
This updates the version wpf-gpu-raster which adds support for
GPUs/drivers that use truncation instead of rounding when converting
vertices to fixed point.
It also adds the GL vendor to InitContextResult so that we can detect
AMD on macOS and tell wpf-gpu-raster that truncation is going to happen.
Differential Revision: https://phabricator.services.mozilla.com/D167503
This patch adds most of the underlying infrastructure for a new
tiled (previously: segmented) rendering path to webrender. It is
initially used only by simple (non-masked) rectangles. Follow
up patches will extend this first to all rectangles and then
porting other primitives to use this new rendering path.
The new primitive is encoded in the command buffer structure,
which allows efficiently encoding arbitrary sets of commands
to be read by the batching code. The batching code for this
primitive is much simpler, and should be consistent and shared
when other primitives are ported to use this path.
Tiling is handled during the prepare pass per-primitive. It can
support edge AA tiles, different regions for clip-mask corners
(to be added in a follow up), and uniform tiling for the inner
section of the primitive (e.g. for tiled image masks).
It adds specific support for edge anti-aliasing to be considered
as part of the tiling configuration for a primitive. This both
improves performance of rotated but otherwise opaque primitives
and allows additional functionality we don't currently support
(such as applying AA along one edge of a 2d but subpixel aligned
primitive). Since SWGL provides native AA support, the patches
take account of that, and avoid the vertex shader work and extra
edge primitives when SWGL is enabled.
Follow up patches will:
- Add clip-mask support to new rendering path
- Port other primitives to new rendering path
- Add SWGL shader fast-paths where profiling indicates it makes sense to
- Remove old segment / mask rendering paths once no longer used
Other minor changes included as part of this patch:
- Pack TransformPaletteId in 24 bits instead of 32, for better instance struct packing
- Support prepare pass appending multiple command buffer instructions per primitive
Differential Revision: https://phabricator.services.mozilla.com/D167629
A long time ago we blocked this on Adreno 630 due to causing strange
shader linking errors. We have recently discovered that this can also
affect Adreno 620 devices too.
Differential Revision: https://phabricator.services.mozilla.com/D167941
Before these patches we were adding the titlebar height even though we
were not rendering it.
This made an apz mochitest with hardcoded heights to fail on macOS.
It also perturbed browser_html_scroll_restoration.js in a way such as
the scroll position after a resize is rounded in a different direction,
but that is harmless.
Depends on D166431
Differential Revision: https://phabricator.services.mozilla.com/D167027
Rename AllowedTouchBehavior::DOUBLE_TAP_ZOOM to ANIMATING_ZOOM, and
CompositorHitTestFlags::eTouchActionDoubleTapZoomDisabled to
eTouchActionAnimatingZoomDisabled while at it.
Differential Revision: https://phabricator.services.mozilla.com/D167522
The function ANativeWindow_fromSurface() takes a jobject that is
supposed to be a Surface. Prior to bug 1706656 GeckoSurface was a
subclass of Surface, meaning we passed the correct type. However,
GeckoSurface no longer derives from Surface meaning we hit this JNI
crash.
To fix this, call GeckoSurface->GetSurface() to get the underlying
Surface object.
Note that this code path is only active if the user has modified the
pref gfx.use-surfacetexture-textures. So although the volume is high,
it appears to be limited to a small number of users.
Differential Revision: https://phabricator.services.mozilla.com/D167659
On Android, GPU process exists by default. When GPU process does not exist, an error should disable GPU process.
On Android, WebGL handling process could easily crash. The crash could trigger disable GPU process. Current out-of-process WebGL implementation creates WebGLParent in parent process. Then a crash in parent process could be triggered by WebGL. Then it seems better to disable out-of-process WebGL when GPU process does not exist.
And it seems also better to disable accelerated canvas, since it uses WebGL for acceleration.
Differential Revision: https://phabricator.services.mozilla.com/D167512
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
We only use it to generate a dummy URI for SVG-in-Opentype documents. We
don't really need the URIs to be unique or anything in practice.
I noticed this code while looking at the load flags set up for
bug 1809006.
Differential Revision: https://phabricator.services.mozilla.com/D166291