Its only user was the BSPTree test suite, for its purposes
define a TestPolygon using an empty BSPTestData class instead.
Differential Revision: https://phabricator.services.mozilla.com/D162929
This fixes a bug which caused Firefox windows to become frozen after some time.
Full credit goes to Susan and RandyS for bisecting the regressor of this bug, and
to Jeff DeFouw for debugging the issue and finding the cause.
The bug here is a "state race" between the VsyncDispatcher state and
the VsyncSource state. Both are protected by locks, and the code that
runs in those locks respectively can see a different orders of invocations.
VsyncDispatcher::UpdateVsyncStatus does this thing where it updates its state inside
a lock, gathers some information, and then calls methods on VsyncSource *outside* the lock.
Since it calls those methods outside the lock, these calls can end up being executed
in a different order than the state changes were observed inside the lock.
Here's the bad scenario in detail, with the same VsyncDispatcher being used from
two different threads, turning a Remove,Add into an Add,Remove:
```
Thread A Thread B
VsyncDispatcher::UpdateVsync
|
|----> Enter VsyncDispatcher lock
| | VsyncDispatcher::UpdateVsync
| | state->mIsObservingVsync = false |
| | (We want to stop listening) |
| | |
|<---- Exit VsyncDispatcher lock |
| |----> Enter VsyncDispatcher lock
| | |
| | | state->mIsObservingVsync = true
| | | (We want to start listening)
| | |
| |<---- Exit VsyncDispatcher lock
| |
| |----> Enter VsyncSource::AddVsyncDispatcher
| | |
| | |----> Enter VsyncSource lock
| | | |
| | | | state->mDispatchers.Contains(aVsyncDispatcher)
|----> VsyncSource::RemoveVsyncDispatcher | | | VsyncDispatcher already present in list, not doing anything
| | | | |
| | | |<---- Exit VsyncSource lock
| | | |
| | |<---- Exit VsyncSource::AddVsyncDispatcher
| |----> Enter VsyncSource lock
| | |
| | | Removing aVsyncDispatcher from state->mDispatchers
| | |
| |<---- Exit VsyncSource lock
| |
|<---- Exit VsyncSource::AddVsyncDispatcher
```
Now the VsyncDispatcher thinks it is still observing vsync, but it is
no longer registered with the VsyncSource.
This patch makes it so that two calls to AddVsyncDispatcher followed by one call
to RemoveVsyncDispatcher result in the VsyncDispatcher still being registered.
AddVsyncDispatcher is no longer idempotent.
Differential Revision: https://phabricator.services.mozilla.com/D162760
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
This in effect reverts part of bug 1756400, so that we only do the full
per-language fontconfig substitution processing for locales that use
CJK or Arabic script. These are the locales where it is likely that
there may be custom per-language/locale font preferences that need to
be respected.
(In theory fontconfig could be set up with per-language rules even for
distinctions like 'en-US' vs 'en-GB', or 'en' vs 'fr' vs 'de', etc.,
and we will no longer respect these. But it is almost vanishingly unlikely
that separate font mappings for such distinctions will really be needed,
and the cost of doing all the lookups separately for every lang tag,
even within simple writing systems like Latin, is excessive.)
No automated tests, as this is heavily dependent on the system configuration.
Differential Revision: https://phabricator.services.mozilla.com/D162304
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
mSkippedComposite's purpose is to keep track of the fact that the window is not up to date because the previous composite was skipped. This informs RetrySkippedComposite that a new frame is needed to get the latest changes rendered. As soon as we successfully schedule a composite know that the latest changes are en route to be rendered so we don't need RetrySkippedComposite to push an additional frame later.
Differential Revision: https://phabricator.services.mozilla.com/D162297
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
According to crash data, some devices by OPPO and realme and OnePlus seem to
crash when using Font Match API. I would like to disable it until root cause
finds.
Differential Revision: https://phabricator.services.mozilla.com/D162185
By default, BorrowSnapshot is pessimistic and forces DrawTargetWebgl to return a data snapshot on
the assumption that the snapshot might be used off thread. However, if we actually know the DrawTarget
we're going to be drawing the snapshot to, then we can check if they're both DrawTargetWebgls with
the same internal SharedContext. In that case, we can use a SourceSurfaceWebgl snapshot which can
pass through a GPU texture to the target. This requires us to plumb the DrawTarget down through
SurfaceFromElement all the way to DrawTargetWebgl to make this decision.
Differential Revision: https://phabricator.services.mozilla.com/D162176
When we fallback without recreating the GPU process, we should ensure
that the gfxVar updates have been processed before recreating the
compositor sessions. This is achieved by blocking on the sync
PGPU::SendDeviceStatus IPDL message. This additional sync message only
happens during fallback and thus should be fairly cheap.
Differential Revision: https://phabricator.services.mozilla.com/D162020
It seems like Chrome allows this and it's relatively common.
We don't have a good reason to continue blocking these profiles.
Differential Revision: https://phabricator.services.mozilla.com/D162024
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
* Remove workaround for a long-fixed LLVM bug
* Remove extra flags on pixman-mmx.c
* Remove unneeded -Winline flags
* Drop SIMD exceptions for macOS
* Use correct MMX define
* Enable all SIMD optimizations for Intel builds
* Clean up platform-specific logic
* Enable aarch64 optimizations on Android & Linux
Besides removing a lot of old cruft and improving general readability, this
also re-enables MMX optimizations (the define changed upstream and wasn't
updated in moz.build to reflect that) along with unconditionally compiling
with all available Intel SIMD optimization levels. Pixman does runtime CPU
feature detection, so this should be safe. It also enables AArch64
optimizations on Android and Linux.
Depends on D161868
Differential Revision: https://phabricator.services.mozilla.com/D161869
Removes patches which are no longer being applied to our import and
updates the patches that are applied to the current upstream.
Differential Revision: https://phabricator.services.mozilla.com/D161867
This in effect reverts bug 1798036 for desktop Linux, as the fix there
was really only needed for Android, and turns out to conflict with how
the FC-based backend handles variations.
Tested locally; currently no reftest because we cannot assume presence
of an installed variable font.
Differential Revision: https://phabricator.services.mozilla.com/D161958
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
We are seeing a number of crashes in glShaderSource on old Mali
devices (T628, T720, and T760). It's difficult to see what the problem
is without more information, but as a shot in the dark this patch
ensures we null- terminate the source strings before passing them to
the driver.
Differential Revision: https://phabricator.services.mozilla.com/D161894
This is needed so that UnscaledFontFreeType::CreateScaledFont can later call CloneFace
if it needs to apply variation settings.
Tested locally with an emulator running Android 13; not testable in CI as the older Android
versions we have there don't use the new variable-font version of Roboto.
Differential Revision: https://phabricator.services.mozilla.com/D161762
Currently splane splitters are stored in the built scene and reallocated with every new scene.
This patch moves the responsibility of storing/recycling the plane splitters to the frame builder so that they can be reused in more cases. The scene builder only needs to track splitter indices, it doesn't use the splitter objects themselves.
Alone this patch does not make a large difference because the current version of the plane_split crate reallocates everything each frame. The next version of plane_split does a much better job of recycling allocations, and applying this patch on top of it makes a large difference.
Differential Revision: https://phabricator.services.mozilla.com/D160363
New plane_split version with much faster BSP tree.
The main source of churn is plane_split not being generic over the unit tag anymore.
Differential Revision: https://phabricator.services.mozilla.com/D160362
Add basic tests for transform notifications for pan gestures with and without
momentum pans that follow the initial pan gesture.
Differential Revision: https://phabricator.services.mozilla.com/D159565
Do not fire multiple scrollend events for one pan gesture that triggers a
momentum pan. On pan-end queue a state change event to be dispatched to
the content controller in 100ms. Note that this patch does not alter
the the internal APZC state change, but only delays the notification
dispatched to the content controller.
Differential Revision: https://phabricator.services.mozilla.com/D159540
Bug 1661147 made us correctly inherit the clip chain. We do fix up the
scroll id etc before pushing a new ASR override etc, but we didn't fix
up the clip chain ID.
Differential Revision: https://phabricator.services.mozilla.com/D161382
There was still a timing that hit the assert. When ClientWebGLContext::Event_webglcontextrestored() was called just before ClientWebGLContext::UpdateWebRenderCanvasData() the assert was failed.
Differential Revision: https://phabricator.services.mozilla.com/D161243
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
In practice, it's only instantiated on the stack; and that's kinda important,
to reduce the likelihood that it somehow outlives the 'gfxSkipChars' instance
that it maintains a raw pointer to and is iterating over.
Differential Revision: https://phabricator.services.mozilla.com/D159922
For SWGL on ARM, we implement sqrt(N) as N * inversesqrt(N). This means we don't
properly handle zero unless we explicitly check for it. Otherwise, a NaN ends up
getting produced erroneously.
Differential Revision: https://phabricator.services.mozilla.com/D161107
It feels really ugly to do this, as the problem is a badly-designed font,
not a bug in Gecko's behavior. But given that it's a standard Windows font,
I think it's probably worth having the workaround.
Differential Revision: https://phabricator.services.mozilla.com/D160820
With this, which should not change behavior unless we were about to crash,
the testcase completes successfully (although slowly, as it's generating
an 8000-plus page PDF document).
Differential Revision: https://phabricator.services.mozilla.com/D160675
Port gradient stops to be stored in the gpu-buffer rather than
the gpu-cache. The intent is to land a small use case for the
gpu-buffer code, which will allow us to get an idea if there's any
unexpected performance or driver bugs from the new gpu-buffer code,
before making wider use of this to replace the gpu-cache.
Differential Revision: https://phabricator.services.mozilla.com/D160743
This test ensures that a y-flip works correctly along with a 90/270
degree transform and a non-square content size.
Depends on D160817
Differential Revision: https://phabricator.services.mozilla.com/D160818
Gecko uses the webrender API DisplayListBuilder.push_computed_frame()
to create a reference frame with a transform specified by a scale_from
size, an optional vertical_flip, and a rotation. This is used for
video.
This patch adds the ability to test this API from wrench yaml. An
example of a test using this capability can be found in the next patch
in this series.
Depends on D160816
Differential Revision: https://phabricator.services.mozilla.com/D160817