about:support's feature table still shows blocklisting, just not whether
the pref is set.
If different from default, dom.webgpu.enabled still shows up in about:support under
"Important Modified Prefs" like normal.
Also renames "gfx.webgpu.force-enabled" to "gfx.webgpu.ignore-blocklist"
to reflect its functionality.
Differential Revision: https://phabricator.services.mozilla.com/D169007
If the glslopt pass fails to optimize a shader, we helpfully print the
shader source so that it is easy to find what the problem is. However,
we print this from within the build_parallel call, meaning if multiple
shaders fail to optimize we print all of their sources and they get
interleaved with each other, making it very difficult to find the
problematic line.
This patch makes us delay printing the source until the same place
where we print the error log, after we have stopped processing in
parallel. This means we will only print the source of a single
shader (the first one which fails to optimize), along with the error
log for that shader, which is much easier to debug.
This also includes a small tidy-up to handle both vertex and fragment
shaders in a loop to remove code duplication, and runs rustfmt.
Differential Revision: https://phabricator.services.mozilla.com/D169618
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
This is actually a bug that pre-dates the regression here, but I haven't seen a report
of it or a specific test failure that results. However, the new WPT reftests I'm
intending to land for the slant issue do exhibit a failure until this is fixed,
so let's go ahead and do it here.
Differential Revision: https://phabricator.services.mozilla.com/D169334
Bug 1638709 describes artifacts when the webrender compositor is enabled
on certain Windows systems with NVIDIA cards and mixed monitor refresh
rates. As of bug 1704954, we currently disable DirectComposition on such
systems in Beta and Release as a mitigation.
Unfortunately, on a significant (albeit not yet fully characterized)
fraction of Windows 11 machines, the fallback compositor also has
issues, resulting in bug 1763981 (clipping of web content on first
entering fullscreen). Users experiencing this latter issue have hitherto
_not_ reported the former when testing on Nightly, suggesting that the
mitigation may be getting applied overbroadly.
Add a pref to allow disabling the mitigation in question, so that users
experiencing bug 1763981, but who are not subject to 1638709, have a
less intrusive workaround than remembering to hit F11 twice every time
they start Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D169389
In bug 1809738 we found that our scissored render target clear
optimization actively hurt performance on some Mali GPUs. From testing
on a variety of Android devices, we have found that it mostly makes no
difference either way, but hurts performance on some other GPUs
too. On software webrender, however, it is still a performance win.
This patch therefore disables the optimization on all Android, apart
from when using software webrender.
Differential Revision: https://phabricator.services.mozilla.com/D169062
GCC 13s libstdc++ reduced its dependency on some headers like <cstdint>,
so it's no longer transitively included through various headers.
Include it explicitly.
See also: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
11:16.32 .../components/telemetry/pingsender/pingsender.cpp:30:7:
error: unknown type name 'uint32_t'
11:16.33 const uint32_t kConnectionTimeoutMs = 30 * 1000;
11:16.33 ^
11:16.33 ... /components/telemetry/pingsender/pingsender.cpp:76:9:
error: unknown type name 'uint32_t'
11:16.33 const uint32_t kBufferSize = 4 * 1024 - 1;
11:16.34 ^
11:16.44 2 errors generated.
(et al)
Differential Revision: https://phabricator.services.mozilla.com/D167491
Similar to the other GetCurrentAsync*() functions,
GetCurrentAsyncVisualViewport() takes into account the async test
attributes as well as the frame delay.
It supersedes GetCurrentAsyncScrollOffsetInCSSPixels() which can
be obtained as the the TopLeft() of the visual viewport rect.
Differential Revision: https://phabricator.services.mozilla.com/D163148
+ 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
This enables my local build to achieve 60fps on the js1k demo linked from the bug,
whereas without the patch I get barely 10fps.
Note: it's still possible for ComputePointAtLength would perform poorly if
the caller is iterating backwards or doing random access to a long path.
A potential mitigation for that would be to add an mLength field to FlatPathOp,
storing the length-so-far of the path, so that ComputePointAtLength could do
a binary search instead of linear accumulation. But this would add significant
memory overhead, and may not be worth doing; the low-overhead cursor here
appears to be enough to make text-on-a-path perform much better.
Differential Revision: https://phabricator.services.mozilla.com/D168937
Turns out we already had code for this in NumericTools.h, so reuse it.
I thought I was going to need this code somewhere else though I didn't
end up needing it.
While at it clean up unnecessary template params I noticed.
Differential Revision: https://phabricator.services.mozilla.com/D168460
Implementation is borrowed from RenderAndroidSurfaceTextureHost. Since Android SurfaceTexture and AndroidHardwareBuffer use same android GraphicBuffer.
Differential Revision: https://phabricator.services.mozilla.com/D168764
Currently, the rounded rect shader uses the linear distance from the corner's origin
(the ellipse origin) to select which corner to evaluate ellipse distance within. However,
this metric may fail when it believes we are currently inside multiple corners, and may
select the wrong minimal distance and thus the wrong corner. Ideally, we need to actually
compute the ellipse distance for each corner and select the minimal one, but this is
prohibitively expensive.
Instead, we use the same strategy as the SWGL span shader which is to define a half-space
plane that spans the diagonal of each corner, by which we decide if we are inside a given
corner by seeing which side of the coner diagonal's half-space plane we're on. This yields
code that is about as fast as the currently broken linear distance comparison and more
closely matches the results of the SWGL span shader as a bonus.
This also cleans up the half-space varyings to be specified in a more common plane form
of normal and offset which takes up less space while being a bit cheaper to evaluate.
Differential Revision: https://phabricator.services.mozilla.com/D168769
EffectNV12 is not used by RenderCompositorOGLSWGL/RenderCompositorLayersSWGL. EffectRGB is used by RenderCompositorLayersSWGL.
Differential Revision: https://phabricator.services.mozilla.com/D168771
This patch reverts our behaviour closer to how we worked prior to bug
1780193. Parts of bug 1780193 remain because they are necessary to
ensure there are no race conditions when interacting with the cache from
multiple threads.
Now we remove fonts from the expiration tracker when there are strong
references remaining to the object. When the last strong reference is
cleared, we readd the font to the expiration tracker. A lookup will
remove it from the tracker (and creates a strong reference). If it
expires from the tracker, it is then destroy. There are several race
conditions we need to manage because the refcount can be updated without
holding the gfxFontCache mutex.
Differential Revision: https://phabricator.services.mozilla.com/D156716
2 problems existed.
- [1] RenderAndroidSurfaceTextureHost::GetUvCoords() was not called when RenderAndroidSurfaceTextureHost is wrapped by RenderTextureHostWrapper.
- [2] NeedsYFlip() of SurfaceTextureHost::CreateRenderTexture() uses TextureHost::mFlags. But TextureHost::mFlags was updated by RemoteTextureHostWrapper::ApplyTextureFlagsToRemoteTexture() after SurfaceTextureHost::CreateRenderTexture() call. Then RenderAndroidSurfaceTextureHost::mOriginPos became wrong.
[1] is addressed by adding RenderTextureHostWrapper::GetUvCoords()
[2] is addressed by removing RenderAndroidSurfaceTextureHost::mOriginPos. It is not necessary since Bug 1731980.
Differential Revision: https://phabricator.services.mozilla.com/D168763
Disable external compositing if ImageRendering is not ImageRendering::Auto for now. It seems that we could not handle ImageRendering::Pixelated for video overlay on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D168514
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
This is:
* An easier way for browser code to access it.
* Avoids having a bunch of per-platform implementations.
* We don't need to actually get graphics info for it to work.
So it should be a bit nicer over all.
Differential Revision: https://phabricator.services.mozilla.com/D168373
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/D168464
We currently set a scissor rect when clearing render targets, as this
was measured to be a performance win on some GPUs. On Mali, however,
it is better to perform a full, non-scissored clear of a render target
immediately after binding it, as this allows the driver to omit
reading the previous contents in to tile memory. This patch makes it
so that by default we perform the non-scissored clear on Mali, and
retain the scissor on all other GPUs. The existing
enable_clear_scissor option can be used by the embedder to override
the default value.
Of particular note, this massively improves the performance of twitter
on Mali G710 (eg Pixel 7), where the blur backdrop-filter uses several
intermediate render targets and the scissored clear causes noticable
stutter.
Differential Revision: https://phabricator.services.mozilla.com/D168465
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
This will be needed by the draw compositor which can't own the device renderer's device but needs to use it. Other implementations can just ignore the parameter.
Differential Revision: https://phabricator.services.mozilla.com/D165958
It was used for occlusion culling with the z-buffer, but we moved away from using the depth buffer in the draw compositor.
Depends on D165141
Differential Revision: https://phabricator.services.mozilla.com/D165142
Now that fixed position content will have the mScrollParentId set to the
null scroll parent id, the warning posted for non-root APZC's overscrolled
with a null scroll parent id should not fire for APZCs with a fixed
position parent.
Differential Revision: https://phabricator.services.mozilla.com/D166445
Use the hit-testing tree to determine the APZC to handoff overscroll to
if the current APZC is in a fixed position subtree.
Differential Revision: https://phabricator.services.mozilla.com/D166787
Now that we're using `EGL_KHR_no_config_context`, this attribute request is no longer necessary.
Even worse, support for it already been removed by upstream ANGLE. So, let's remove it before we try
to upgrade ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D167038
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
When available, we should use the [`EGL_KHR_no_config_context` extension] inside of
`GLContextEGL::CreateEGLPBufferOffscreenContext`. The usage of this extension will be necessary to
accommodate incoming upstream changes in ANGLE, which have [migrated away][incoming-breakage] from
[our usage of `EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE` in
`gfx/webrender_bindings/RenderCompositorANGLE.cpp`][what-will-be-broken] in favor of this standard
extension. Luckily it's forwards-compatible to start consuming it now!
This revision changes a few things that are linked:
- Separate assignment and usage of a surface context from that of a context.
- Rename `GLContextEGL::mConfig` to `mSurfaceConfig` to better reflect its usage; it's only ever
used to create surfaces, not contexts.
Split out from @jgilbert's D164308 and D164309.
[`EGL_KHR_no_config_context` extension]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
[incoming-breakage]: ad8e4d99a9
[what-will-be-broken]: https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/gfx/webrender_bindings/RenderCompositorANGLE.cpp#668
Differential Revision: https://phabricator.services.mozilla.com/D166708
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
Now that we're using `EGL_KHR_no_config_context`, this attribute request is no longer necessary.
Even worse, support for it already been removed by upstream ANGLE. So, let's remove it before we try
to upgrade ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D167038
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
When available, we should use the [`EGL_KHR_no_config_context` extension] inside of
`GLContextEGL::CreateEGLPBufferOffscreenContext`. The usage of this extension will be necessary to
accommodate incoming upstream changes in ANGLE, which have [migrated away][incoming-breakage] from
[our usage of `EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE` in
`gfx/webrender_bindings/RenderCompositorANGLE.cpp`][what-will-be-broken] in favor of this standard
extension. Luckily it's forwards-compatible to start consuming it now!
This revision changes a few things that are linked:
- Separate assignment and usage of a surface context from that of a context.
- Rename `GLContextEGL::mConfig` to `mSurfaceConfig` to better reflect its usage; it's only ever
used to create surfaces, not contexts.
Split out from @jgilbert's D164308 and D164309.
[`EGL_KHR_no_config_context` extension]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
[incoming-breakage]: ad8e4d99a9
[what-will-be-broken]: https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/gfx/webrender_bindings/RenderCompositorANGLE.cpp#668
Differential Revision: https://phabricator.services.mozilla.com/D166708
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
Due to a bug on versions of Android prior to 8.0, attempting to create
a SurfaceTexture from an isolated process results in an infinite
hang. We must therefore avoid doing this.
We currently create a dummy SurfaceTexture in order to call the
Surface constructor when instantiating a GeckoSurface from a
Parcel. This patch avoids this by making GeckoSurface own a Surface
rather than inherit from one.
Additionally, for every Surface allocated we create a corresponding
"sync" SurfaceTexture in the content processes. This is used when the
texture data is required in the content process, eg using video as a
WebGL texture upload source. This patch prevents us allocating such
SurfaceTextures. If out-of-process WebGL is enabled, video data can
still be used as a texture upload source as WebGL resides in the GPU
process. However, if out-of-process WebGL is disabled the texture
upload will fail.
Prior to shipping isolated content processes on affected Android
versions, we must therefore ensure we have an alternative solution to
using video as a WebGL texture upload source, or that out-of-process
WebGL can be relied upon.
Differential Revision: https://phabricator.services.mozilla.com/D165970
Due to a bug on versions of Android prior to 8.0, attempting to create
a SurfaceTexture from an isolated process results in an infinite
hang. We must therefore avoid doing this.
We currently create a dummy SurfaceTexture in order to call the
Surface constructor when instantiating a GeckoSurface from a
Parcel. This patch avoids this by making GeckoSurface own a Surface
rather than inherit from one.
Additionally, for every Surface allocated we create a corresponding
"sync" SurfaceTexture in the content processes. This is used when the
texture data is required in the content process, eg using video as a
WebGL texture upload source. This patch prevents us allocating such
SurfaceTextures. If out-of-process WebGL is enabled, video data can
still be used as a texture upload source as WebGL resides in the GPU
process. However, if out-of-process WebGL is disabled the texture
upload will fail.
Prior to shipping isolated content processes on affected Android
versions, we must therefore ensure we have an alternative solution to
using video as a WebGL texture upload source, or that out-of-process
WebGL can be relied upon.
Differential Revision: https://phabricator.services.mozilla.com/D165970
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
RemoteTextureMap::GetRemoteTextureForDisplayList() has enough asserts. The assert in RemoteTextureHostWrapper::CheckIsReadyForRendering() could be removed.
Differential Revision: https://phabricator.services.mozilla.com/D166886
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
For example, given that
`surface_rect`: `Box2D((0.0, -1.04904175e-5), (588.99994, 0.0))`
`surface bound`: Box2D((0.0, -512.0), (1024.0, 0.0))
Then doing round_out() after translating the surface_rect with
`-surface_bounds.min.to_vector()` results an empty rect.
We need to make sure that negative origin `surface_rect` is not collapssed.
Differential Revision: https://phabricator.services.mozilla.com/D166887
Also rename helper_zoomToFocusedInput_nozoom.html to
helper_zoomToFocusedInput_nozoom_bug1738696.html, since it
appears to test behaviour specific to bug 1738696.
Differential Revision: https://phabricator.services.mozilla.com/D166837
This shouldn't change visible behavior, but it makes painting glyphs
that have many layers under a PaintComposite operation -- some of the
Noto flag glyphs have hundreds of layers! -- substantially faster by
avoiding the need to explicitly walk the paint graph to determine the
temporary surface bounds.
On my local Windows build, this reduces the "jank" of first-time
switching to the flags page of the example from 2400ms to around 900ms;
still a bit sluggish but greatly improved. Subsequently switching away
from and back to the flags, the jank reduces to around 110ms.
(Interestingly, the perf issue here seems to be much worse on Windows
than on macOS or Linux; apparently getting glyph paths via DirectWrite
is more expensive than on the other platforms.)
Differential Revision: https://phabricator.services.mozilla.com/D166782
Ideally, this pref wouldn't be exposed to users at all, because if a user
changes the value, it will cause our telemetry to be over or under sampled
for that user. That's a small risk to take since most users don't change
pref values.
Differential Revision: https://phabricator.services.mozilla.com/D160963
GLReadTexImageHelper::ReadTexImage() in RenderAndroidSurfaceTextureHost::ReadTexImage() needs to take care of gl::OriginPos.
Differential Revision: https://phabricator.services.mozilla.com/D166406
On Android Emulator, multi buffer mode SurfaceTexture is used for WebGL gl::SharedSurface.
When SurfaceTexture is not single buffer mode, RenderAndroidSurfaceTextureHost does not call mSurfTex->UpdateTexImage() during rendering with WebRender(Software OpenGL).
Differential Revision: https://phabricator.services.mozilla.com/D166132
On Android Emulator, multi buffer mode SurfaceTexture is used for WebGL gl::SharedSurface.
When SurfaceTexture is not single buffer mode, RenderAndroidSurfaceTextureHost does not call mSurfTex->UpdateTexImage() during rendering with WebRender(Software OpenGL).
Differential Revision: https://phabricator.services.mozilla.com/D166132
On Android emulator, android fence sync is not supported. It caused the problem. Current RemoteTextureMap re-use gl::SharedSurface as stack. It seemed to cause the problem. If the recycling is done as queue, timing of it's recycling can be delayed.
By using queue, recycling of gl::SharedSurface works same as to non-RemoteTextureMap.
Differential Revision: https://phabricator.services.mozilla.com/D166018
The spec is still using `Scroll-linked`, so we exclude the change of WPT tests.
I believe WPT will get updates once the spec doc is renamed.
Differential Revision: https://phabricator.services.mozilla.com/D165914
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
Didn't investigate why this was failing exactly, but promiseApzFlushedRepaints does not wait for a refresh driver tick and I remember from fixing some other scrolling tests a while back that sometimes you need to wait for a refresh driver tick for things to be completed (don't remember the details).
Differential Revision: https://phabricator.services.mozilla.com/D165546
- Add tests for overscroll handoff from a fixed position element
- Add test for overscroll handoff from a sticky position element
Differential Revision: https://phabricator.services.mozilla.com/D148662
A few of the crashes here are happening via other codepaths, so we should protect those as well.
None of this changes any behavior except in the case where a disk error or similar failure happens
within DWrite calls; the goal here is to handle such failures safely, just treating the affected
font as unusable and allowing us to fall back to something else rather than crash.
Depends on D165524
Differential Revision: https://phabricator.services.mozilla.com/D165525
The majority of the crashes I looked at here are happening under ReadFaceNamesForFamily.
We already have an SEH guard aronud part of the method, but it doesn't cover all the potentially
problematic DWrite calls, so this patch moves more of the code inside the try/except block
to attempt to handle exceptions safely.x
Differential Revision: https://phabricator.services.mozilla.com/D165524
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
This should marginally improve content-process startup for processes that don't immediately
need to use the system font. No actual change in behavior, just taking the initialization
of the system-font faces out of the startup path.
Differential Revision: https://phabricator.services.mozilla.com/D165386
It will ensure that the BrowserTestUtils.waitForContentEvent has finished
setting up the event listener in content before sending native pan events.
Differential Revision: https://phabricator.services.mozilla.com/D165344
+ 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 already had logic for reclamping the visual viewport offset if the
composition bounds changes, but since the composition bounds is in
ParentLayer (post-zoom) coordinates, this didn't handle the case where
the zoom changes.
Differential Revision: https://phabricator.services.mozilla.com/D164998
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
Note, changes to the delayed-result codepath are not required because
touched prevented by touch-action always get an eager HandledByContent
result.
Differential Revision: https://phabricator.services.mozilla.com/D164586
The function would combine "has room to scroll (or zoom)" and
"touch action allows scroll (or zoom)", but in future patches
APZ will behave differently in the two cases.
Differential Revision: https://phabricator.services.mozilla.com/D164581
This effectively backs out the fix for bug 1746336, while keeping the test
added in that bug (PanZoomControllerTest#touchActionWithWheelListener)
passing using a different fix approach (remembering the eager status
and using it in the computation of the delayed result).
Differential Revision: https://phabricator.services.mozilla.com/D164114
This brings in various bugfixes and improvements from upstream,
including the fix for bug 1791809 and a workaround for bug 1804530.
In this update, `wgpu_core` leaves the selection of backends to its
users, rather than trying to guess which backends to use itself, based
on the target architecture and operating system. For Firefox, this
means that `gfx/wgpu_bindings/Cargo.toml` is now responsible for
selecting back ends.
Firefox's WebGPU implementation should never use `wgpu`'s GLES
backend. Firefox can now explain this to `wgpu-core`, causing it to
drop its dependency on `glow`, `bitflags_serde_shim` and `slotmap`.
These are no longer vendored, and their exemptions in
`supply-chain/config.toml` can be dropped.
The new `wgpu-core` updates to version 0.37.1+1.3.235 of the `ash`
crate, and this patch moves ash's supply-chain exemption forward to
the new version. We expect to finish vetting that next week, but
because this `wgpu-core` update is urgently needed, we want to extend
the exemption for the time being.
The dependency on `slotmap` had been patched to an empty file in
`build/rust/dummy-web`, which can now be removed.
The new `wgpu-core` no longer uses `cfg_aliases`, so Firefox no longer
needs to vendor that.
Differential Revision: https://phabricator.services.mozilla.com/D164928
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
This helps out when clipping to rects with canvas2d. It reduces GPU
usage on the React-Stockcharts benchmark from ~70% down to ~45% on
a desktop gen9 Intel GPU.
It would be better to handle this in the D2D backend like we do in other
backends, but there's not an easy way to detect rectangle paths there.
This was the easiest place to slot it in and shouldn't have too high a
cost for the other places we use the recording backend.
Differential Revision: https://phabricator.services.mozilla.com/D164764
Bug 1798242 did not cause a regression. Then it seems OK to try to enable video overlay without ZeroCopyNV12Texture with non-intel GPUs to release.
Differential Revision: https://phabricator.services.mozilla.com/D164634
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
Previously we were querying the current ARRAY_BUFFER_BINDING, which
would fail if you did:
```
BindBuffer(ARRAY_BUFFER, a)
VertexAttribPointer(...)
BindBuffer(ARRAY_BUFFER, b)
```
We would assume we should call VeretxAttribPointer again with `b` bound,
when we need to bind `a` instead.
Unfortunately, this is hard to test, and we only hit this on drivers
where we don't use VAOs, which are rare now.
Differential Revision: https://phabricator.services.mozilla.com/D164744
When we did the major cairo update in bug 739096, most of our old patch files were superseded
and no longer relevant, but I failed to clean them up at the time. So here, we remove all the
old patch files, and create new ones just for the fixes we've applied on top of the new code
from upstream.
I've omitted patch files for fixes that I am aware have already landed upstream, as those will
automatically be included in any future update we take. (It's possible more of the new patch
files will also be obsolete by the time we try pulling a new version, but at least they should
provide a starting point.)
Differential Revision: https://phabricator.services.mozilla.com/D164680
This updates the docker image used for CI on the github.com webrender
repository, so that updates to the WebRender code can continue to be
propagated to github.
Differential Revision: https://phabricator.services.mozilla.com/D164458
Bug 1236323 disabled clang's -Wimplicit-fallthrough warnings from some Skia headers, but this warning can be re-enabled because the current version of Skia doesn't trigger these warnings.
Depends on D164027
Differential Revision: https://phabricator.services.mozilla.com/D164028
Device reset in test_device_reset.html replaces CompositorBridgeChild to a new one. And shutting down old CompositorBridgeChild also destroys TextureClients.
Differential Revision: https://phabricator.services.mozilla.com/D164175
Kelsey Gilbert
sotaro
stransky
Jamie Nicol
Alex Jakobi
Andi-Bogdan Postelnicu
Cristina Horotan
Gijs Kruitbosch
Ray Kraesig
Ashley Hale
Jonathan Kew
Cristian Tuns
Razvan Cojocaru
Nicolas Silva
Csoregi Natalia
Arsen Arsenović
Botond Ballo
Norisz Fay
Otto Länd
Emilio Cobos Álvarez
Makoto Kato
Nika Layzell
Lee Salzman
Andrew Osmond
Neil Deakin
Glenn Watson
Jan-Erik Rediger
Tom Schuster
Jeff Muizelaar
Hiroyuki Ikezoe
Erich Gubler
Mark Banner
Chris H-C
Butkovits Atila
Marian-Vasile Laza
Dan Robertson
Iulian Moraru
Stanca Serban
Jim Blandy
Robert Longson
Sandor Molnar
Brad Werth
Joel Maher
Timothy Nikkel
Boris Chiou
Sylvestre Ledru
Olli Pettay
Zach Hoffman
Marco Castelluccio
Sasaki Keiya
Mike Hommey
David Shin
Andrew McCreight
Kartikaya Gupta
Chris Peterson