The intension behind this change is that we want to factor out openSelectPopup
and hideSelectPopup in an independnt js file to reuse the functions for
different browser tests but unfortunately factoring out the hideSelectPopup
causes the following lint error;
> ChromeUtils.import should not be called with (..., null) to retrieve the JSM
> global object. Rely on explicit exports instead.
> mozilla/reject-chromeutils-import-null (eslint)
As of now, there is an on-going work to fix ChromeUtils.import calls with `null`
(bug 1609271) and the reason why the same error doesn't happen in the head.js is
the file is excluded from lint targets [1]. Fixing the error properly requires
SelectChild.jsm modifications so we defer the issue to bug 1609271 and re-use
the head.js directly instead.
[1] https://searchfox.org/mozilla-central/rev/6a6a366031680829746b5d2362610b868fd9571a/.eslintrc.js#511
Depends on D104365
Differential Revision: https://phabricator.services.mozilla.com/D104366
Since bug 1650183, the value returned by this function is not
necessarily the composition size of the RCD-RSF, but may be
a smaller size suitable for bounding the composited size of
scroll frames in a given process.
Differential Revision: https://phabricator.services.mozilla.com/D104463
This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
We add a shared surface on the main thread to the shared surfaces table
when in the compositor process because it uses a different wrapper
object if the shared surface is in a different process. This structure
was mirrored for the removal of a shared surface created in the
compositor process, however that created a race between the main thread
freeing the surface before the display list creation bound an image key
to the shared surface's external image ID. As such, this patch makes
removal always post to the compositor thread, whether in the compositor
process or not.
Differential Revision: https://phabricator.services.mozilla.com/D104426
In bug 1687394, the semantics of `requested_raster_space` were
changed to only take effect when an intermediate surface was
created.
However, this causes a regression to snapping with text runs
that are animated on the root surface (such as loading spinner
glyphs).
To fix that, while also keeping the functionality of the previous
patch (removing a source of pass-through pictures), there is now
a stack of requested raster space pushed and popped for each
stacking context. This is read and stored by text runs during
scene building, ensuring that these animated glyphs select the
correct raster space to avoid snapping / jittering bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104345
The resource namespace associated with a WebRenderBridgeChild can change
over time, e.g. due to a tab being moved between windows. We need to
recreate any resource keys as a result of this. The missing glyph atlas
code assumed the namespace was constant, and this could cause issues by
referencing invalid image keys, or even another unrelated image. This
patch makes it properly track the entire image key, not just the handle,
so that it can manage namespace changes properly.
Differential Revision: https://phabricator.services.mozilla.com/D104336
The result of compute_aa_range depends on fwidth(local_pos). In the no-perspective case,
the derivatives of local_pos are constant across an entire primitive. SWGL fast-paths only
run in the no-perspective case anyway, so it is convenient to compute the aa_range once
for the entire span and then reuse it, factoring out this per-pixel cost.
Differential Revision: https://phabricator.services.mozilla.com/D104294
When we change the namespace, we discard all cached resources and their
associated keys from the WebRender cache. As such if any transaction
comes in with the old namespace ID, we can safefully discard the entire
update, since we will need to recreate any that we are using anyways.
This patch also adds new asserts to ensure we never get old namespace
IDs for individual keys in a valid resource update. This should never
happen in practice.
Differential Revision: https://phabricator.services.mozilla.com/D104236
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
This removes some calls to commit_span from inside the draw_span specializers.
Instead it relies upon the span rasterizer loop to do some of the work, which
will incur a function pointer call in the rare case we actually return out
of a specializer early. This shouldn't be that performance critical and will
remove some inliner bloat.
Also, I refactored commit_output in the rasterizer itself to hopefully cause
fewer template instantiations which should also further reduce inliner bloat.
Differential Revision: https://phabricator.services.mozilla.com/D104150
When we change the namespace, we discard all cached resources and their
associated keys from the WebRender cache. As such if any transaction
comes in with the old namespace ID, we can safefully discard the entire
update, since we will need to recreate any that we are using anyways.
This patch also adds new asserts to ensure we never get old namespace
IDs for individual keys in a valid resource update. This should never
happen in practice.
Differential Revision: https://phabricator.services.mozilla.com/D104236
GfxInfo::RefreshMonitors() could not be called in ScreenHelperWin::RefreshScreens(), since the RefreshScreens() is called within nsAppShell::Init(). Then GfxInfo::RefreshMonitors() is called during WM_DISPLAYCHANGE event handling.
Differential Revision: https://phabricator.services.mozilla.com/D103661
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
In the case that we have a painted minimal display port apzc knows about the scroll frame already, it just has the minimal amount of painted content. So we can tell apz right away. Note that the async transform for minimal dp's are still the identity so we'll still jank minimap dp's before the painted regular dp reaches the apzc.
Differential Revision: https://phabricator.services.mozilla.com/D103858
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
This change had previously been backed out due to causing rendering
issues on HTC 10 Android, and some Linux Radeon cards (bug 1687554).
On the HTC 10, the issue was that the extra case statement added to
the text run shader caused the glslopt optimized shader to become too
complex for the device, resulting in rendering issues. Since bug
1689316 has landed, the optimized shader output is simpler and this
issue is avoided.
On radeon, we have established that the problem is due to the format
of the texture and that the shader is fine. Furthermore, the shader
works correctly with either R8 or RGBA8 texture data, as all of the
channels contain the alpha value in the RGBA8 textures. Therefore we
continue to use RGBA8 textures for alpha glyphs on Linux Radeon, but
switch to R8 on other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D104082
This patch adds a diagnostic assert to check if the namespace of the
blob image key matches the current namespace of the process's
WebRenderBridgeChild. Other long lived users of image keys (i.e. shared
surfaces produced by imagelib) have to check to ensure their cached
image keys haven't gone out of scope due to a namespace update (e.g. tab
moved to a new window, GPU process crash). The caching for blob images
however is very different and should be cleared in these cases. This
assert will confirm this.
Differential Revision: https://phabricator.services.mozilla.com/D104066
This patch adds a diagnostic assert to check if the namespace of the
blob image key matches the current namespace of the process's
WebRenderBridgeChild. Other long lived users of image keys (i.e. shared
surfaces produced by imagelib) have to check to ensure their cached
image keys haven't gone out of scope due to a namespace update (e.g. tab
moved to a new window, GPU process crash). The caching for blob images
however is very different and should be cleared in these cases. This
assert will confirm this.
Differential Revision: https://phabricator.services.mozilla.com/D104066
GfxInfo::RefreshMonitors() could not be called in ScreenHelperWin::RefreshScreens(), since the RefreshScreens() is called within nsAppShell::Init(). Then GfxInfo::RefreshMonitors() is called during WM_DISPLAYCHANGE event handling.
Differential Revision: https://phabricator.services.mozilla.com/D103661
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
Previously, we've taken the strategy of exposing any gecko specific hooks
as traits. The disadvantage of this approach is that it requires plumbing
a boxed trait through to any places that need to use it.
With this approach, we add global functions that don't do anything when
compiled without the 'gecko' feature. This makes it easier to add hooks
and avoids the plumbing which should reduce friction in the process
of moving more stuff out of gecko and into webrender.
Differential Revision: https://phabricator.services.mozilla.com/D102334
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
We currently don't ever set non-rectilinear transforms on our CALayers, so there
is no need for anti-aliasing. Explicitly disabling edge anti-aliasing means that
there are no seams between tiles when the window server draws our window with a
transform, such as during Mission Control.
Differential Revision: https://phabricator.services.mozilla.com/D103740
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
This assert fails on the new reftest from this bug, on Android.
I haven't dug into it too deeply, given that it's code that'll be going away at
some point soon (hopefully), but I think what happens is that we have a fixed
layer which is not annotated as fixed. That's normal for background-attachment:
fixed root backgrounds. We handle explicitly-annotated-as-fixed layers a bit
further up in this function.
Returning false here seems like a very safe thing to do.
Depends on D54855
Differential Revision: https://phabricator.services.mozilla.com/D103736
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#4866
scrollOffsetUpdated gets set to true if we get basically any scroll update, including a NewScrollFrame update that we create for every new scroll frame that just informs apzc the scroll offset is (0,0).
scrollOffsetUpdated being true means RequestContentRepaint gets called a little later. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports.
This bug is to fix the regression caused by bug 1662013. Two other bugs also regressed this (bug 1627012 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687926 is filed for the regression from bug 1627012.
Before https://hg.mozilla.org/integration/autoland/rev/b78646d59e32 we only set scrollOffsetUpdated to true if GetScrollOffsetUpdated() was set to true on the metrics, and it didn't get set to true for new scroll frames.
Differential Revision: https://phabricator.services.mozilla.com/D102587