Still missing:
cargo update -p glean
mach vendor rust
These steps should be done once application-services is updated to pull
in a single version of UniFFI.
Differential Revision: https://phabricator.services.mozilla.com/D219729
As part of out expanding performance metrics for resource usage we are adding the cpuTime metric to track CPU time in various performance tests on mobile and desktop tests for firefox browsers only
Differential Revision: https://phabricator.services.mozilla.com/D217146
On Android, SurfaceTextures provide a transform that should be applied
to texture coordinates when sampling from the texture. Usually this is
simply a y-flip, but sometimes it includes a scale and slight
translation, eg when the video frame is contained within a larger
texture. Previously we ignored this transform but performed a y-flip,
meaning we rendered correctly most of the time, but not all of the
time.
Our first attempt to fix this was in bug 1731980. When rendering as a
compositor surface with RenderCompositorOGLSWGL, we supplied the
transform to CompositorOGL's shaders, which correctly fixed the bug
for this rendering path.
However, the attempted fix for hardware webrender in fact made things
worse. As UV coordinates are supplied to webrender unnormalized, then
the shaders normalize them by dividing by the actual texture size,
this effectively handled the scale component of the transform. (Though
not quite scaling by the correct amount, and ignoring the translation
component, sometimes resulting in a pixel-wide green seam being
visible at the video's edges.) When we additionally applied the
transformation to the coordinates, it resulted in the scale being
applied twice, and the video being rendered too far zoomed
in.
To make matters worse, when we received subsequent bug reports of
incorrect rendering on various devices we mistakenly assumed that the
devices must be buggy, rather than our code being incorrect. We
therefore reverted to ignoring the transform on these devices, thereby
breaking the software webrender path again.
Additionally, on devices without GL_OES_EGL_image_external_essl3
support, we must sample from the SurfaceTexture using an ESSL1
shader. This means we do not have access to the correct texture size,
meaning we cannot correctly normalize the UV coordinates. This results
in the video being rendered too far zoomed out. And in the
non-compositor-surface software webrender path, we were accidentally
downscaling the texture when reading back into a CPU buffer, resulting
in the video being rendered at the correct zoom, but being very
blurry.
This patch aims to handle the transform correctly, in all rendering
paths, hopefully once and for all.
For hardware webrender, we now supply the texture coordinates to
webrender already normalized, using the functionality added in the
previous patch. This avoids the shaders scaling the coordinates again,
or using an incorrect texture size to do so.
For RenderCompositorOGLSWGL, we continue to apply the transform using
CompositorOGL's shaders.
In the non-compositor-surface software webrender path, we make
GLReadPixelsHelper apply the transform when reading from the
SurfaceTexture in to the CPU buffer. Again using functionality added
earlier in this patch series. This avoids downscaling the image. We
can then provide the default untransformed and unnormalized UVs to
webrender. As a result we can now remove the virtual function
RenderTextureHost::GetUvCoords(), added in bug 1731980, as it no
longer serves any purpose: we no longer want to share the
implementation between RenderAndroidSurfaceTextureHost::Lock and
RenderTextureHostSWGL::LockSWGL.
Finally, we remove all transform overrides on the devices we
mistakenly assumed were buggy.
Differential Revision: https://phabricator.services.mozilla.com/D220582
Some external images must be sampled from by providing normalized UV
coordinates to webrender, but currently webrender only supports
unnormalized UVs.
This patch adds a flag to webrender's external image API that
specifies whether the UV coordinates supplied when the texture is
locked are normalized or unnormalized. This flag is plumbed through
webrender to the required locations. We then add support for taking
normalized UVs as inputs to the brush_image and cs_scale shaders. The
only other shader that can be used with external textures is the
composite shader, which already supports normalized UVs.
This does not change any behaviour, that will happen in the next patch
in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220581
Add the capability to transform the texture coordinates when reading
from a texture, similar to existing support in GLBlitHelper and
CompositorOGL.
This patch doesn't change any behaviour, but this capability will be
made use of by a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220580
The behavior applied when using just the address bar was already doing this, now
the behavior applied when using the navbar will do the same.
Differential Revision: https://phabricator.services.mozilla.com/D220868
This ensures that the measured height of (toolbar + navbar) - used in the setVerticalClipping
Call will be the same as the computed height of (toolbar + navbar) used in the
setDynamicToolbarMaxHeight call.
Will also bring a more cohesive UI between the home and browser screens which is always good.
Differential Revision: https://phabricator.services.mozilla.com/D220867
On a real device with a density of 2.75 1dp is measured as 3px while with using toInt()
we'd calculate it to be 2px.
roundToInt() gives the expected result (closest integer) and is also what is used
internally by compose for similar operations.
Differential Revision: https://phabricator.services.mozilla.com/D220866
* Remove condition in tabs.js that prohibited overflow attribute being added for vertical orientation
* Remove redundant overflow-y:auto for #tabbrowser-arrowscrollbox and set a min-height for vertical tabs
Differential Revision: https://phabricator.services.mozilla.com/D221133
A recent change introduced returning `true` in DynamicDownloadDialogBehavior's
`layoutDependsOn` method to signal to the framework that the download finished dialog
depends on the bottom toolbar.
While technically correct given the complexity of the entire layout the download finished
dialog had it's own View depending on it - the snackbar which may show when users would
tap to open a link in a new tab. And in this scenario we would get a crash.
The approach here comes to restore the previous behavior - return `false` from the
`layoutDependsOn` method, written exactly as it was before.
Differential Revision: https://phabricator.services.mozilla.com/D221469
These shouldn't have any effect in rendering:
* We are full-height because we're in a vertical flexbox with flex:1.
* We are full-width because that's the default flexbox behavior.
So let's minimize unneeded styling differences with and without sidevar.revamp.
Differential Revision: https://phabricator.services.mozilla.com/D221452
Seems bug 1886847 missed this. Ideally light/dark themes will remain in
sync with browser-custom-colors.css more automatically, to avoid
introducing windows system theme differences from our default themes.
Differential Revision: https://phabricator.services.mozilla.com/D221450
This is a preparation for Bug 1708022 and Bug 1917512.
Current webgpu::Adapter and webgpu::Device do not expose if they support ExternalTexture usage in SwapChain. Then CanvasContext could not dynamically detect if the Device supports ExternalTexture usage in SwapChain.
The change add a capability to check it.
Differential Revision: https://phabricator.services.mozilla.com/D221423
Ben Dean-Kawamura
Jan-Erik Rediger
Mozilla Releng Treescript
Paul Zuehlcke
mcarare
Arturo Mejia
Roger Yang
Moritz Beier
David Shin
sarah541
Dão Gottwald
Chris H-C
Cristian Tuns
Emilio Cobos Álvarez
DJ
Vlad Dreghici
ffxbld
Yury Delendik
andrej
Randell Jesup
Jamie Nicol
Dave Townsend
Daisuke Akatsuka
Julian Descottes
Mugurell
Sarah Clements
Noemi Erli
tannal
Sean
Valentin Gosu
Iulian Moraru
sotaro
Ryan VanderMeulen