WebRender internally reverses gradient stops when they are ordered from right to left. This is done while building the GPU data and the gradient cache key stored the reversed stops without sepcifying if they were revered or originally in that order. This meant that if a page had two similar gradients with the only difference being that on was reversed but not the other, they could end up using the same cache key and one of the two would not be rendered properly.
This patch includes a boolean in the cache key to make sure reversed gradients don't accidentally use the same key as similar non-reversed gradients.
Differential Revision: https://phabricator.services.mozilla.com/D113975
Large segment bounds trip an assertion when casting coordinates to integers. Clipping early also reduces the amount of cached pixels.
Differential Revision: https://phabricator.services.mozilla.com/D113819
Large gradients are cached scaled down and stretched back by the image brush. Because the scaling factor is non-uniform the shader has to take it into account. The previous implementation was incorrectly accounting for the scale.
Differential Revision: https://phabricator.services.mozilla.com/D113753
The original triangle winding check was designed to be run inside the span
rasterizer every time the edges changed. However, at present, this only ever
gets used once at the very top of the triangle to determine winding and then
assumes winding is constant thereafter.
This updates the check to work on these assumptions to be simpler and less
fragile where numerical precision is concerned. If we can assume the candidate
edges both start on the same row, then the check boils down to seeing if they
share the same starting point and doing a cross-product.
Differential Revision: https://phabricator.services.mozilla.com/D113900
Rather than have SwCompositor or the individual RenderCompositors track this, it seems easier
to just have WR itself avoid calling add_surface or start_compositing if we're inside an update.
Differential Revision: https://phabricator.services.mozilla.com/D113953
We have to look at the element or its parent to fix the wikipedia case because there is a display block div inside the table cell.
Differential Revision: https://phabricator.services.mozilla.com/D113341
This is what Safari does, i.e. once after a swipe gesture has started to a
direction where there is no navigation history, then even if the swipe gesture
switched to the opposite direction where navigation can happen, swipe navigation
will never happen. Chrome looks like they are trying to do swipe navigation in
such cases, but it looks like they sometimes fail it, the swipe navigation
indicator (an arrow image) doesn't show up sometime when the swipe navigation
goes to the opposite direction.
This change fixes stuck-in-overscroll situations where user swipes horizontally
to a direction where navigation is impossible during overscrolling, but doesn't
fix situations where navigation is possible but the user cancels the navigation.
To fix the later situations we need a different fix apart from this change.
The mochitest in this change doesn't test the stuck-in-overscroll situations at
all because we need to write a browser mochitest since swipe gesture is
implemented as a browser feature but unfortunately SpecialPowers.snapshotWindow
doesn't capture overscrolled gutter regions for some reasons, so instead the
test checks whether the swipe gesture module keeps capturing wheel events in the
situations where navigation is impossible.
Differential Revision: https://phabricator.services.mozilla.com/D113636
We have to look at the element or its parent to fix the wikipedia case because there is a display block div inside the table cell.
Differential Revision: https://phabricator.services.mozilla.com/D113341
Large gradients are cached scaled down and stretched back by the image brush. Because the scaling factor is non-uniform the shader has to take it into account. The previous implementation was incorrectly accounting for the scale.
Differential Revision: https://phabricator.services.mozilla.com/D113753
This was a performance optimization that we no longer care about.
Removing it will avoid the need to merge the additions into the new
cairo-quartz-surface code from upstream.
Differential Revision: https://phabricator.services.mozilla.com/D112556
In the testcase from the bug we have an overflow hidden document that is being scrolled by the pages javascript. In this case the scrollable rect (aka cssPageRect here) has its position as the scroll offset and the size is the composition size in css pixels. In this case we want to behave as if the scroll position is not movable (since it's not movable by the user), so we only want to be able to zoom to something that is in the visible rect. Staying inside the scrollable rect also makes sense, and we want to do it, for the non-overflow hidden case.
The current code assumes that the scrollable rect starts at 0.
Differential Revision: https://phabricator.services.mozilla.com/D113253
Because adding or removing a scrollbar can change without the resolution changing (in particular, when zooming in we can add scrollbars) and we don't want to detect that content has updated it's resolution and override our (apz) resolution in that case.
This happens when double tapping creates a scrollbar and the resulting repaint updates the apz resolution while the zoom animation is ongoing, messing it up for a frame.
Adding a field for frame metrics just for this is kind of gross, but it can go away when that todo is fixed in NotifyLayersUpdated.
Differential Revision: https://phabricator.services.mozilla.com/D113303
The code in ZoomToRect that calculate the rect to zoom out to does not work if the page is horizontally scrollable, and our min zoom does not allow us to zoom out to fit the full page width.
For example, the targetZoom might get set to 0.1 and our min zoom is 1. The target zoom would get updated to 1, but the scroll offset of the rect wouldn't get adjusted for the new zoom.
So change how we calculate it by taking the min zoom and then calculating the scroll offset so the old visible area is centered in the new visible area.
Differential Revision: https://phabricator.services.mozilla.com/D113329
In the testcase from the bug we have an overflow hidden document that is being scrolled by the pages javascript. In this case the scrollable rect (aka cssPageRect here) has its position as the scroll offset and the size is the composition size in css pixels. In this case we want to behave as if the scroll position is not movable (since it's not movable by the user), so we only want to be able to zoom to something that is in the visible rect. Staying inside the scrollable rect also makes sense, and we want to do it, for the non-overflow hidden case.
The current code assumes that the scrollable rect starts at 0.
Differential Revision: https://phabricator.services.mozilla.com/D113253
This was a performance optimization that we no longer care about.
Removing it will avoid the need to merge the additions into the new
cairo-quartz-surface code from upstream.
Differential Revision: https://phabricator.services.mozilla.com/D112556
Bug 1705599 made the calculation we do in nsLayoutUtils::GetBoundingFrameRect work if its inside fixed content. But bug 1701749 added a similar calculation in DoubleTapToZoom.cpp which we didn't fix up for the same problem.
Differential Revision: https://phabricator.services.mozilla.com/D113334
This is a waste because we don't render that content, and if we did (we do sometimes, and it leads to flashing) it would be low resolution in the case of zooming out. It also causes bugs like bug 1698537. And if we get some other updates in there we can get stuck in a state where we half think we are zoomed in and half think we are zoomed out.
See bug 1698537, comment 11 for full back story.
Differential Revision: https://phabricator.services.mozilla.com/D113074
We request a repaint at the start of a zoom at the after zoom, which ends up causing us to request repaints during the whole zoom animation (the reasons for this are explained in the bugzilla comment linked below). The repaint request at the start of a zoom animation is weird because it asks for the after zoom, which leads to other problems, and we want to stop doing that. But the repaints during the zoom are beneficial in some ways, they make sure that we dont' checkerboard (too much).
See Bug 1698537, comment 11 for a longer writeup.
Depends on D113072
Differential Revision: https://phabricator.services.mozilla.com/D113073
Previously, it was implicitly disallowed by some checks in the wheel
handling code (e.g. CanScrollWithWheel()), but some cases (like
instant scroll where the starting position is away from the edge)
slipped through the cracks.
Differential Revision: https://phabricator.services.mozilla.com/D113459
This makes the only existing place where we check
OverscrollHandoffState::mScrollSource express the check in a
more semantic way.
Differential Revision: https://phabricator.services.mozilla.com/D113457
If we have a zoom in progress the zoom stored in the sampled state is older than the one on the apzc. So clamping the scroll offset in the sampled state needs to use the zoom on the sampled state (it's used implicitly in this calculation), because the zoom on the sampled state is the one that we will draw to the screen with.
For more background see Bug 1698537, comment 11, second last paragraph.
Differential Revision: https://phabricator.services.mozilla.com/D113072
32bit build Firefox and 64bit Firefox could have same build ID. Pointer size check could be used to recognize if build is different.
Differential Revision: https://phabricator.services.mozilla.com/D113467
We were already clipping off most of the AA inside cs_clip_image previously anyway.
Given that it is too unpredictable in what situations the little bit of remaining
AA was actually applying, and that it causes visual artifacts sometimes when it
activates where it shouldn't, we're better off just using a rough clip inside this
shader for everything so that it is always predictable.
Differential Revision: https://phabricator.services.mozilla.com/D113545
Currently, reftest-content uses GfxInfo::GetInfo() to obtain information about
the Azure backend. GetInfo() uses Win32k APIs, and therefore will mostly
return garbage in content processes.
This adds a new way to obtain the same information directly from GfxInfo
without using Win32k APIs.
Differential Revision: https://phabricator.services.mozilla.com/D111890
The code that decompose linear gradients inserts fake gradient stops to deal with the potential constant color areas before and after the gradient endpoints. The offsets of these extra stops were computed without accounting for the transformation the loop does in the case of reversed stops. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D113290
In bug 1680087 we disabled webrender's partial present feature on
Mali-T6xx and T7xx devices due to rendering issues caused by a buggy
implementation in the driver. We have now seen reports of the same
issue on a Mali-T8xx device.
This patch expands the block to include all Mali-Txxx devices. As a
follow up we should make this dependent on the driver version, so
that users with working drivers can take advantage of the feature.
Differential Revision: https://phabricator.services.mozilla.com/D113477
We have code for this, it's disabled for elements that are 90% or greater the width of the viewport. This code was added in bug 1204084 for the "double tap on tall element" problem and the 90% hasn't been touched since. I can't think of a good reason why we would want to scroll to the top of the element if its 90% the width of the viewport or more.
Differential Revision: https://phabricator.services.mozilla.com/D113335
Recent changes in cs_clip_image are exposing some cases where we are letting rectangles being warped
by perspective transform get considered as axis-aligned. This makes the axis-alignment check stronger
for clipping to guard against the Z dependency in the W coordinate that is messing up clipping.
Differential Revision: https://phabricator.services.mozilla.com/D113259
On Fenix we see many users with a value of opengl for the
gfx_status_compositor telemetry probe, despite the fact they are
running versions of gecko for which webrender should be enabled on
their device.
The theory is that although gecko is being initialized the user has
not opened a tab, and therefore initialized a compositor, since they
have been updated to a version which should be running webrender by
default. To verify that this is the case, this patch adds a new probe
gfx_status_last_compositor_gecko_version, which reports the gecko
version at the time a compositor is initialized. This will be used to
confirm that the users whose compositor unexpectedly reports opengl
have indeed not initialized a compositor in a while.
Differential Revision: https://phabricator.services.mozilla.com/D112339
Using native compositor integration should imply the y-flip can be
done by the system compositor - this is true for CA, DC and Wayland.
As the Wayland backend now does so, remove the
surface_origin_is_top_left support again, making sure
the Wayland backend uses the same code paths as CA/DC backends do.
Note:
- In order to not regress bug 1680128, do not revert the override
of `SurfaceOriginIsTopLeft()` in `RenderCompositorNative.h`
- Explicitely set `surface_origin_is_top_left: false` in the example
compositor. This is the default, however setting it explicitely
would have helped me bring up the Wayland example compositor.
This is purely a hint for potential future backends.
Differential Revision: https://phabricator.services.mozilla.com/D113217
This makes our parsing of parametric transfer functions
more clear because you can see exactly what output variables
the input variables map to.
Differential Revision: https://phabricator.services.mozilla.com/D113224
To be precise the root APZC should actually be scrollable in the opposed
directions of the given input, it's checked in
AsyncPanZoomController::GetOverscrollableDirections.
Differential Revision: https://phabricator.services.mozilla.com/D113061
To be precise the root APZC should actually be scrollable in the opposed
directions of the given input, it's checked in
AsyncPanZoomController::GetOverscrollableDirections.
Differential Revision: https://phabricator.services.mozilla.com/D113061
Nicolas Silva
Emilio Cobos Álvarez
Jeff Muizelaar
Jed Davis
Jonathan Kew
Lee Salzman
Timothy Nikkel
Hiroyuki Ikezoe
Butkovits Atila
Botond Ballo
Dorel Luca
Robert Mader
Alexandru Michis
Brindusan Cristian
sotaro
Chris Martin
Jamie Nicol
Andi-Bogdan Postelnicu
Andrew Osmond
Brad Werth
imoraru