Because of the way the canvas 2D implementation juggles between path builders and paths, we have to keep track of current and first points in the path, in case a builder is created out of it.
Differential Revision: https://phabricator.services.mozilla.com/D33757
--HG--
extra : source : c79b3af2395894b449731fccdd9eb006b4d0189e
This brings DrawTargetCairo and DrawTargetD2D1 inline with DrawTargetSkia's
ability to handle SourceSurfaceOffset properly.
Differential Revision: https://phabricator.services.mozilla.com/D33536
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
It would have been nicer and more logical to use a MacIOSurfaceImage to store the colorspace information, however the data passed around is a IOSurface Id via a SurfaceDescriptorMacIOSurface; the original data structure isn't kept; so we must transit the data at the same time as the IOSurface Id.
Also remove unnecessary test (new operator is infallible).
Differential Revision: https://phabricator.services.mozilla.com/D26058
--HG--
extra : moz-landing-system : lando
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
The upcoming WebXR API (Bug 1419190) requires intermediate calculations of real-world space coordinates to have more precision with larger ranges. I expect that double precision matrix and quaternions will also be useful in other graphics and layout work.
It would not be ideal to expand the existing classes to always use double precision, as it would incur a significant performance penalty on certain platforms (eg, Arm). The double-precision variants should be used only when required.
The existing gfx::Matrix4x4 and gfx::Quaternion implementation can be extended with templates to generate both single and double precision variants.
Differential Revision: https://phabricator.services.mozilla.com/D22010
--HG--
extra : moz-landing-system : lando
This eliminates the need to additionally modify gfx.logging.level on
non-debug builds to make apz.printtree output show up.
Differential Revision: https://phabricator.services.mozilla.com/D23880
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
This lets us restrict the size of the mask surface that we allocate
to the destination tile size. This gives a large performance
improvement.
It also includes some miscelanous fixes to the CreateClippedDrawTarget
code path.
Differential Revision: https://phabricator.services.mozilla.com/D21750
DTO = DrawTargetOffset = (-Origin.x, -Origin.y)
CTM = CurrentTransform
MASKT = MaskTransform = Inv(CurrentTransform)
MASKO = MaskOffset = (GetRect().x, GetRect().y)
The transform to device space is:
MASKT * CTM * DTO
Currently we do:
MASKT = MASKT * MASKO
Which gives us MASKT * MASKO * CTM * DTO. This works fine if there's no scale but
will not properly cancel out if there is.
I believe we want:
MASKO * MASKT * CTM * DTO
To get this we need to preTranslate instead of postTranslate.
Differential Revision: https://phabricator.services.mozilla.com/D21604
And #include "BufferUnrotate.h" in BufferUnrotate.cpp for BufferUnrotate() function prototype.
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/2d/BufferUnrotate.cpp:17:6 [-Wmissing-prototypes] no previous prototype for function 'BufferUnrotate'
gfx/2d/DrawTargetCairo.cpp:195:6 [-Wmissing-prototypes] no previous prototype for function 'ReleaseData'
gfx/2d/DrawTargetCairo.cpp:201:18 [-Wmissing-prototypes] no previous prototype for function 'CopyToImageSurface'
gfx/2d/DrawTargetCairo.cpp:239:18 [-Wmissing-prototypes] no previous prototype for function 'GetAsImageSurface'
gfx/2d/DrawTargetCairo.cpp:251:18 [-Wmissing-prototypes] no previous prototype for function 'CreateSubImageForData'
gfx/2d/DrawTargetCairo.cpp:272:18 [-Wmissing-prototypes] no previous prototype for function 'ExtractSubImage'
gfx/2d/DrawTargetCairo.cpp:308:18 [-Wmissing-prototypes] no previous prototype for function 'GetCairoSurfaceForSourceSurface'
gfx/2d/DrawTargetRecording.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetRecording.cpp:272:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingFontUserDataDestroyFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:358:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordFontUserDataDestroyFunc'
gfx/2d/FilterNodeSoftware.cpp:1816:6 [-Wmissing-prototypes] no previous prototype for function 'IsAllZero'
gfx/2d/FilterNodeSoftware.cpp:183:37 [-Wmissing-prototypes] no previous prototype for function 'CloneAligned'
gfx/2d/MacIOSurface.cpp:442:6 [-Wmissing-prototypes] no previous prototype for function 'MacIOSurfaceBufferDeallocator'
gfx/2d/QuartzSupport.mm:38:6 [-Wmissing-prototypes] no previous prototype for function 'cgdata_release_callback'
gfx/2d/ScaledFontMac.cpp:191:10 [-Wmissing-prototypes] no previous prototype for function 'CalcTableChecksum'
gfx/2d/ScaledFontMac.cpp:224:5 [-Wmissing-prototypes] no previous prototype for function 'maxPow2LessThan'
gfx/2d/unittest/TestCairo.cpp:12:6 [-Wmissing-prototypes] no previous prototype for function 'TryCircle'
Differential Revision: https://phabricator.services.mozilla.com/D20263
--HG--
extra : rebase_source : b42bce33ed899caeb89e462d99a5cde29a9bb559
extra : intermediate-source : 7923cc86a6394bcd2fb3b7e38f458a5180d31e11
extra : source : 02388f2454e8842d2c023bf9f9fab222d8130093
Bug 1516062 turns on NEON when using gcc and clang. But windows compiler uses
clang-cl, so I would like to turn on it even if windows.
Differential Revision: https://phabricator.services.mozilla.com/D19281
--HG--
extra : moz-landing-system : lando
This isn't the prettiest solution but it's minimally invasive. More long-term a better solution may be to expose a call on DrawTargets to ensure their initialization even if they're on the main thread. IsValid probably isn't a good candidate for this as we want it to be usable freely on the main thread to ensure none of the basic conditions of the surface are still valid.
Differential Revision: https://phabricator.services.mozilla.com/D18339
--HG--
extra : rebase_source : 2b2f05a247ea8c6896288624c5620501592e3dcc
This lets us avoid drawing the complete input for ever tile when
drawing filters into a tile.
Differential Revision: https://phabricator.services.mozilla.com/D17686
--HG--
extra : moz-landing-system : lando
This forwards to an underlying source surface but also has an origin that it
uses to correctly return results from GetRect()
Differential Revision: https://phabricator.services.mozilla.com/D17692
--HG--
extra : moz-landing-system : lando
This is needed so that we can use SourceSurfaces that don't have a
implicit 0,0 origin like those that would come from a DrawTargetTiled
or DrawTargetOffset.
Differential Revision: https://phabricator.services.mozilla.com/D17684
--HG--
extra : moz-landing-system : lando
This fixes a situation where a Device Reset occurs during initialization, after mDC has already been created but before mBitmap is created. In this case IsValid and EnsureInitialized would previously return 'true' in subsequent calls, since they were only checking for the DC.
This patch makes us properly store the full result of initialization for checking with IsValid and re-runs of EnsureInitialized.
Differential Revision: https://phabricator.services.mozilla.com/D17486
--HG--
extra : rebase_source : a20480486c094e14c3a2f67e5f39b1efbece5c69
Also make a const-correctness fix to PointTyped::WithinEpsilonOf().
Depends on D15974
Differential Revision: https://phabricator.services.mozilla.com/D15975
--HG--
extra : moz-landing-system : lando
RectAbsolute contained a MoveBy(Point) function where Point was not a
template parameter but the actual gfx::Point type. This seems to be an
unintentional copy/paste error. This patch fixes it to be properly
templated.
Differential Revision: https://phabricator.services.mozilla.com/D15135
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
Badly-behaved consumers of DrawTargetRecording can trigger recording of
draw calls that will fail to allocate required draw targets when the
recording is replayed. This patch tries to guard against this by
detecting these situations at record-time rather than crashing at
replay-time. When such a situation is detected, it will crash (for
content processes, to catch such scenarios) or gracefully fail (for
other processes).
Differential Revision: https://phabricator.services.mozilla.com/D11527
--HG--
extra : moz-landing-system : lando
This got added in bug 1429508 and then removed in bug 1451845. Tiled blobs adds tests for this, so it shouldn't break again.
MozReview-Commit-ID: 3azL7SoWlr2
Depends on D10038
Differential Revision: https://phabricator.services.mozilla.com/D10041
--HG--
extra : moz-landing-system : lando
This just makes the existing hack available to all DataSourceSurface implementations by default, since we use different ones with WR.
MozReview-Commit-ID: GVR0rIx8wtD
Depends on D10036
Differential Revision: https://phabricator.services.mozilla.com/D10038
--HG--
extra : moz-landing-system : lando
This got added in bug 1429508 and then removed in bug 1451845. Tiled blobs adds tests for this, so it shouldn't break again.
MozReview-Commit-ID: 3azL7SoWlr2
Depends on D10038
Differential Revision: https://phabricator.services.mozilla.com/D10041
--HG--
extra : moz-landing-system : lando
This just makes the existing hack available to all DataSourceSurface implementations by default, since we use different ones with WR.
MozReview-Commit-ID: GVR0rIx8wtD
Depends on D10036
Differential Revision: https://phabricator.services.mozilla.com/D10038
--HG--
extra : moz-landing-system : lando
This got added in bug 1429508 and then removed in bug 1451845. Tiled blobs adds tests for this, so it shouldn't break again.
MozReview-Commit-ID: 3azL7SoWlr2
Depends on D10038
Differential Revision: https://phabricator.services.mozilla.com/D10041
--HG--
extra : moz-landing-system : lando
This just makes the existing hack available to all DataSourceSurface implementations by default, since we use different ones with WR.
MozReview-Commit-ID: GVR0rIx8wtD
Depends on D10036
Differential Revision: https://phabricator.services.mozilla.com/D10038
--HG--
extra : moz-landing-system : lando
This is only used with DXVA decoder. P016 and P010 are just like NV12 but with 16 bits data..
Depends on D8246
Differential Revision: https://phabricator.services.mozilla.com/D8136
--HG--
extra : moz-landing-system : lando
The methods BytesPerPixel, SurfaceFormatForColorDepth, BitDepthForColorDepth, ColorDepthForBitDepth and RescalingFactorForColorDepth all directly depends on the types defined in Types.h, they also return constant values.
As such it makes more sense to have them defined at the same level where the types themselves are declared.
Depends on D8065
Differential Revision: https://phabricator.services.mozilla.com/D8073
--HG--
extra : moz-landing-system : lando
Additionally, add info for the following type:
R8G8B8
B8G8R8
R8G8
HSV
Lab
DEPTH
Differential Revision: https://phabricator.services.mozilla.com/D8065
--HG--
extra : moz-landing-system : lando
This commit adds an API to DrawTarget to draw a surface that will be provided
at the time a recording is replayed. The surface is referenced using a user
interpreted ID.
This will be used for drawing a OOP iframe, and the ID will be the TabId.
Differential Revision: https://phabricator.services.mozilla.com/D6786
--HG--
extra : rebase_source : d5ce9b429c89e9adb0e5fb180f60125e64f12d4a
This was giving me some font assertion crashes, and changing this as a hunch fixed it.
Differential Revision: https://phabricator.services.mozilla.com/D6784
--HG--
extra : rebase_source : 99bf039f33e314fb6f88ea283cf4cc575b054566
The same is done for NEON, and the check folds to nothing when building
when the build target supports SSE2 and runtime detection is not
necessary.
Differential Revision: https://phabricator.services.mozilla.com/D6129
--HG--
extra : moz-landing-system : lando
In MultiTiledContentClient we can create a DrawTargetTiled with a
different origin than the layer we are painting. We must therefore
ensure when edge-padding that we provide the valid region in the draw
target's device-space rather than layer-space. Not doing so was
causing us to pad out in incorrect directions, causing visible seams.
Differential Revision: https://phabricator.services.mozilla.com/D3993
--HG--
extra : moz-landing-system : lando
This commit exposes a method on DrawTargetCapture to see if it has
captured any drawing commands. This allows us to not dispatch
paint tasks if they will do nothing.
Ideally these tasks would execute instantly on the PaintThread, and
we would never delay sending the layer transaction or block on the
next paint, but with thread starvation and context switches it's
best to just not send them.
MozReview-Commit-ID: 7ywkEDBw6EX
--HG--
extra : rebase_source : c60c1c25d551e4a7c14c529137f8e0babc888466
extra : source : 7ae4c893867a5f7df81e0757d4b4a6a21cbc6986
This commit adds the ability to create a different kind of DrawTargetCapture which
has a limit on the size of which its CaptureCommandList can grow before it is
synchronously flushed to its destination DrawTarget.
Special care is taken to not do a sync flush until we would need to resize
the backing store of the CaptureCommandList. This allows us to not waste
memory we've already allocated.
The async painting content clients are updated to use it, and get a default
value from a new preference.
MozReview-Commit-ID: CJL7ffvaRzR
--HG--
extra : rebase_source : f646862dcef7a480b21dfb7ddb1fa165338ba506
extra : source : b865a866fe5a3257615cb54b7e5e790cc9331988
This commit moves ContentClient from creating a CapturedBufferState for
buffer operations, to performing all of those operations on the
DrawTarget(Capture). Creating a DrawTargetCapture is now performed
by the RotatedBuffer when we BeginPaint, all operations are performed
on this capture, and then it's returned to the ClientPaintedLayer
as a PaintTask.
This commit is an involved refactoring of ContentClient and RotatedBuffer
to get this all to work. Here are the major parts:
1. RotatedBuffer is refactored to always perform operations on a single
DrawTarget, which may be a single DT, dual DT, or capture.
2. RotatedBuffer adds BeginCapture and EndCapture methods to switch
which DT is used in operations
3. ContentClient uses the RB capture methods when we are async painting
4. CC::BeginPaint is refactored to only perform capturing on a single
RotatedBuffer. This is because we can't have the output of one
PaintTask be the input of a different PaintTask due to the design
of the Snapshot API.
a. This can occur, today, by doing a FinalizeFrame only to later
fail to Unrotate the buffer, causing a new RB to be created
and painted into
b. The previous PaintThread code worked because it used the
buffer operations which didn't use Snapshot's
c. This is fixed by not doing FinalizeFrame on a buffer if we
realize we cannot unrotate it, and switching to initializing
a buffer using the front buffer which should be up to date.
d. I don't like touching this code, but it passes reftests,
might be a performance improvement, and I've tested it on
known regressions from the last time I messed up this code.
5. CC::PrepareForPaint is inlined into BeginPaint because dual draw
targets can be cleared correctly from a previous commit
6. The code paths in ClientPaintedLayer are unified because we no
longer need to special case this beyond setting the correct
ContentClient flag.
7. CapturedPaintState and CapturedBufferState are removed in favor
of PaintTask. Additionally EndLayer is no longer needed as all
quadrants of a rotated buffer are in the same capture, so we
don't need special case flushing code.
MozReview-Commit-ID: 9UI40dwran
--HG--
extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b
extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
This commit adds a buffer unrotate operation to DrawTarget. It's
initially implemented with LockBits in DrawTarget. DrawTargetDual
overrides the implementation to pass on the operation to it's
DrawTargets.
No override is given for DrawTargetCapture as we intentionally
avoid this code path when async painting as it can fail.
This is needed so that RotatedBuffer can expose a single DrawTarget,
which can be a DrawTarget (for normal alpha), DrawTargetDual (for
component alpha), or DrawTargetCapture (when async painting).
MozReview-Commit-ID: csjjZ733hl
--HG--
rename : gfx/layers/BufferUnrotate.cpp => gfx/2d/BufferUnrotate.cpp
rename : gfx/layers/BufferUnrotate.h => gfx/2d/BufferUnrotate.h
extra : rebase_source : 5d96e2a5d36a01f2f9992adb37830e56436c7c35
extra : source : 64cb50b227e0ae604653f03ce2e892493126392e
This commit adds the ability to create a SourceSurfaceDual directly,
instead of only from a DrawTargetDual. This allows SourceRotatedBuffer
to expose itself as a single SourceSurface for a later commit.
MozReview-Commit-ID: K21K42cGDy1
--HG--
extra : rebase_source : d3fe48ac711f9cd28799bfd8d36b74750cb15554
extra : source : 392a724d5acd25854e871fa47335c4b938fe9ae1
This commit changes the behavior of DrawTargetDual::Clear to be aware that
it has on-white and on-black buffers, and perform clearing appropriately.
This is slightly against what the DrawTarget documentation says the method
should do, but it allows us to move another paint thread operation into
DrawTargetCapture and simplify our ContentClient implementations.
I haven't seen any obvious breakage with this, and reftests are green.
An alternative would be to add a separate Clear method with documented
difference here.
MozReview-Commit-ID: 65CzcxlRqv7
--HG--
extra : rebase_source : 299adbb02e79f66f7d6860c5fe86784bad8332f8
extra : source : 3dc47f17fa446bb7f2b5876753f8271a93c0e0c8
This commit adds an operation to perform 'edge padding' on a draw
target. By default this is performed using LockBits, but it's
overriden in DrawTargetTiled and DrawTargetCapture to propagate
the call so it functions correctly.
This helps TiledContentClient move from applying this operation
on a per texture client basis, to being able to do it on the
DrawTargetTiled after painting. This in turn helps move all
paint thread operations into DrawTargetCapture.
MozReview-Commit-ID: 2ncOTxGXQfk
--HG--
rename : gfx/layers/BufferEdgePad.cpp => gfx/2d/BufferEdgePad.cpp
rename : gfx/layers/BufferEdgePad.h => gfx/2d/BufferEdgePad.h
extra : rebase_source : a3315644fe31f2a432935dcbfdb9969c58b691e1
extra : source : 699c954992f87db7fc792f5562090de42a8162cb
This lets us avoid filtering the entire source image when we only need a small portion of it.
This makes a big performance difference with tiled blob images with WebRender.
MozReview-Commit-ID: EbMZ7ZJEeCe
--HG--
extra : rebase_source : 3f507ca5776e4ad63ac2ea71f20376519953274c
This adds a DrawTargetOffset which is basically a simplified
DrawTargetTiled that only supports one tile. It useful for situations
where Cairo's device offset was used previously.
This also replaces WebRender's use of DrawTargetTiled which was just trying to
apply offset.
MozReview-Commit-ID: I33PB6CnHh0
--HG--
extra : rebase_source : 9fa51a0180343231cfca41daa0e3fa53f1b7befe
Rendering glyphs at many different rotations was causing the D2D glyph
cache to grow very large. Calling EndDraw/BeginDraw will prune the
cache, but is costly, so only do it for every 1000 glyphs.
MozReview-Commit-ID: HUFpxDvYAzQ
--HG--
extra : rebase_source : de283c5e687da07e5417e0d221d7f45b992080d5
For example, if we set a transform to rotate3d(0, 0, 1e50, 45deg), the
expected normalized rotate axis is (0, 0, 1).
However, the length is larger than the maximum of float, so the actual value is
(0/inf, 0/inf, 1e50/inf) == (0, 0, 0). Therefore, we scale the vector before
doing normalization to avoid getting a zero vector.
MozReview-Commit-ID: 5LUDWD4RuNj
--HG--
extra : rebase_source : eb82f0b3979bf6ea3cd11b643ebb30a49edc24f8
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
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
We can easily use Maybe<DataSourceSurface::ScopedMap> instead of
allocated the map on the heap. This does require some minor changes to
ScopedMap to properly support moves, but should be much more efficient.
Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
We must check mIsMapped inside mChangeMutex or else we could run into a race condition where
the source surface is subsequently mapped again before the function terminates. This was
being hit on try.
MozReview-Commit-ID: 1eot3DVW8VD
--HG--
extra : rebase_source : 19f2514d9e2412ee5fe7c99844b7f64f78a7425e
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
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
Nicolas Silva
Jeff Muizelaar
Lee Salzman
Mihai Alexandru Michis
Jean-Yves Avenard
Gurzau Raul
Jonathan Kew
Andreea Pavel
Sylvestre Ledru
Botond Ballo
Bas Schouten
Csoregi Natalia
Narcis Beleuzu
Gerald Squelart
Jeff Gilbert
Mike Hommey
Kearwood "Kip" Gilbert
Daniel Varga
Kartikaya Gupta
Emilio Cobos Álvarez
Ryan Hunt
Cosmin Sabou
Chris Peterson
Masatoshi Kimura
Makoto Kato
Razvan Maries
Sebastian Hengst
Ehsan Akhgari
Tooru Fujisawa
Andrew Osmond
Matt Woodrow
Brindusan Cristian
arthur.iakab
Ciure Andrei
Cameron McCormack
Jamie Nicol
Jeff Muizelaar
Andi-Bogdan Postelnicu
David Major
Robert Longson
Miko Mynttinen
Robert Bartlensky
Boris Chiou
Hiroyuki Ikezoe
Bob Owen
Jonathan Watt
Tristan Bourvon
Robert Longson