We can't use memcmp to compare PODs, largely because of undefined
padding. The rest of the Pod* functions are fine though, since we're
replicating or zeroing PODs.
MozReview-Commit-ID: LSspAi8qCWw
In the case of an invalid clip-path, the browser is supposed to discard the
mask entirely. In the non-webrender codepath this would happen
implicitly because the computed MaskUsage would have no flags set, and
so no actions would be taken on the gfxContext which contained the
display items rasterized so far. In the WebRender codepath, though, we
invoke the code on a A8 drawtarget that's zero-filled, so if PaintMask
fails to rasterize anything into it, it gets treated as a "mask everything
out" mask. Instead, this patch makes it so that we detect the scenario
where the computed MaskUsage is a no-op, and ensure that we don't apply
the mask in that case.
An alternative approach considered was to initialize the A8 drawtarget to
white instead of black but in cases where there is an actual mask, the
rest of the code assumes it is zero-filled and so that doesn't work.
MozReview-Commit-ID: Hw7nCiUXVJl
--HG--
extra : rebase_source : 241d550fa0ed1b3bd088c73d9565b166acbcece8
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
This improves the DisplayList Mutate Talos test by about 5% on windows, as well as numerous smaller improvements on DisplayList heavy tasks.
MozReview-Commit-ID: tlEtPjqWI4
Instead of hard-cording the root scroll frame id, get the value from
WebRender. This was previously hard-coded to 0, so when WebRender
switched to using 1 for the root scroll frame id, the positioning of
sticky frames were broken in subtle ways. This happened because they
were being parented to a root reference frame (which now uses the 0 id)
instead of the root scroll frame.
MozReview-Commit-ID: 66ArgKHGpWE
--HG--
extra : rebase_source : ff6937bf7fc8d4472eb074d0466c8dcd6fba54a8
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
When comparing a Maybe<WrScrollId> to another WrScrollId we need to properly
handle the case where Nothing() signifies the root scroll frame. This is
equivalent to calling scrollId.valueOr(FrameMetrics::NULL_SCROLL_ID), as was
done before WrScrolLId replaced ViewId in the WebRender ScrollingLayersHelper.
We also have DisplayListBuilder::TopmostScrollId always return a value instead
of a Maybe, since an empty clip stack means that the current scroll id is that
of the root scroll frame.
Previously Nothing() was not equivalent to WrScrollId { 0 }, which caused the
ScrollingLayersHelper to fill the mClipAndScroll value and push another
set of clip and scroll nodes onto the WebRender display list builder.
MozReview-Commit-ID: CeatZlRXtuI
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
Jeff Gilbert
Tiberius Oros
Kartikaya Gupta
Bogdan Tara
Boris Zbarsky
arthur.iakab
Nicolas Silva
Cosmin Sabou
Ciure Andrei
Lee Salzman
Ryan Hunt
sotaro
Joel Maher
Emilio Cobos Álvarez
Eliza Balazs
David Major
Kris Maglione
Bas Schouten
Nika Layzell
Noemi Erli
Ryan VanderMeulen
Martin Robinson
Florian Quèze
Petr Sumbera
Andrew Osmond
Alexis Beingessner