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
Currently, we use a simple merging algorithm, because the more
complicated ones didn't work.
This code won't actually be used until we do blob image invalidation
in a follow up.
MozReview-Commit-ID: Q2Em3QC195
The shared memory handle reporting has been generalized to be an
external handle reporting. This is used for both shared memory, and for
volatile memory (on Android.) This will allow us to have a better sense
of just how many handles are being used by images on Android.
Additionally we were not properly reporting forced heap allocated
memory, if we were putting animated frames on the heap. This is because
we used SourceSurfaceAlignedRawData without implementing
AddSizeOfExcludingThis.
image.mem.volatile.min_threshold_kb is the minimum buffer allocation for
an image frame in KB before it will use volatile memory. If it is less
than it will use the heap. This only is set to > 0 on Android.
image.mem.animated.use_heap forces image frames to use the heap if it is
for an animated image. This is only enabled for Android, and was
previously a compile time option also for Android.
This makes it possible to implement nsDisplayBlend blob image invalidation.
It currently only includes an implementation for Skia and DrawTargetRecording.
All other backends will crash when used.
MozReview-Commit-ID: 2GhdDxi4jHG
This commit introduces a lock on each FilterNodeSoftware around the cached surface.
This lock must be acquired whenever the cached surface is accessed. Currently this
is when the Filter is invalidated or painted.
When painting we only hold the cache lock when determining if we need to compute
a new surface, and after we have computed that new surface. This allows another
thread that may be painting that filter node at a different rect to not contend
on the cache. This is just theoretical though as DrawTargetTiled doesn't clamp
the source rect of the Filter command to the tile rect.
MozReview-Commit-ID: KFVZ35e1czB
--HG--
extra : rebase_source : a22918df80a24fad216a834a5737249cab570f08
This is a just a back out of changeset 6882857e1bb5.
MozReview-Commit-ID: 9Z6iEHl3eAy
--HG--
extra : rebase_source : 3d091c72a6e589e702d90ffe6800e131b009604b
Add a command CreateClippedDrawTarget to DrawTarget, which takes the
max required size and a transform between this draw target and the one
to be created. The created draw target may have its size clipped to
the size of this draw target, transformed to the new target's
space. This means that the new surface will be large enough so
that it is rendered to this draw target correctly, but not necessarily
any larger.
Usually this will just create a draw target of the requested size, for
simplicity. However, when replaying a recorded draw target we do clip
the size to the base draw target's size. This is done using a
DrawTargetTiled, so when applying the mask in PopLayer, we must take
the SourceSurface's offset in to account.
MozReview-Commit-ID: 89ONElphzLu
--HG--
extra : rebase_source : 7eebeb66a2686a7b6f4ade36f3004ebb06abc2fe
Fix the DrawTargetTiled::mRect initialization, and expose through the
virtual function GetRect(). Make SnapshotTiled::GetDataSurface()
allocate a surface the size of this rect, rather the XMost and
YMost. Callers of SourceSurface::GetDataSurface() can query
SourceSurface::GetRect() and apply the necessary offset themselves.
MozReview-Commit-ID: C31FGirQ0oK
--HG--
extra : rebase_source : ac31ae3ca0a0b188f9293c4e6898b4e4a65cad0e
A Box is like a Rect but represented as (x1, y1, x2, y2) instead of
(x, y, w, h).
The API is bare-bones at the moment; it can be extended as needed
by future users.
MozReview-Commit-ID: FWv69Y5hP6t
--HG--
extra : rebase_source : 1f717727bc724842a2f6adcba9e6cbbe50059436
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
OpenType font collections (*.ttc) contain multiple faces in a single file,
identified via index. When creating a font descriptor for a FreeType or
Fontconfig font, we mistakenly set the index to zero, always.
This bug became visible when layout and WebRender would disagree on the face in
use, rendering text with the metrics from the proper face but the outlines of
another. Unless, of course, the selected face was the first (or only) in the
font file.
MozReview-Commit-ID: 73qcPOD0HIr
--HG--
extra : rebase_source : b5784ff547bae99186d646dbb92b31660beb3970
This was leading to a mutex never being unlocked, eventually causing a
crash when it was destroyed.
MozReview-Commit-ID: JzEDWzKxZ4S
--HG--
extra : rebase_source : c86ad738addbec55f33165d300876f4c675cf5f4
This will make it so that we avoid main thread rasterization for box shadows.
MozReview-Commit-ID: 9Tg4dsH21V6
--HG--
extra : rebase_source : 5af0460239ba3d54aca483b07a494e81ed9294d2
This debug only bounds checking is not thread safe to any filter nodes drawing at
the same time. I believe it makes sense to just manually calculate the bounds and
pass them along in the functions that need them.
MozReview-Commit-ID: 9GiYRbWuVF6
--HG--
extra : rebase_source : 388187ef92505a946d4e0a9392353373a9cfeced
Caching SourceSurfaces on a filter node is not thread safe to multiple
threads executing the same filter node at the same time. We could add
a mutex to every filter node and guard on that, but I think it makes
sense to just remove the caching for now. I'm open to readding this,
if this proves to be a problem.
MozReview-Commit-ID: Ca38WlG3V89
--HG--
extra : rebase_source : f0e63b4996928eea5588801d1a724c4a9f3d5040
PowCache is not thread safe to the same filter node being drawn by multiple threads
at the same time. In this case I think it's easiest to just add a mutex for this
filter node.
MozReview-Commit-ID: 7pHuFYGxV4B
--HG--
extra : rebase_source : 3f0d9bc608880082a54b245d2fc4f7b970222a9a
This uses std::floor(T) instead of floor(double) so that we end up calling
floorf(float) for floats instead floor(double). It also changes the literals to
be floats. 0.5f is exactly representable in float and so will transparently
promote to double as needed.
--HG--
extra : rebase_source : ea193026b3c7d1f97f5abbc3f9220eca5ac5523c
This patch was originally developed on bug 1418564.
MozReview-Commit-ID: 53oydIqjhvF
--HG--
extra : rebase_source : 8980cc947b3b8c46a75d032e7e557f39bae08b97
This commit modifies MultiTiledContentClient to record drawing commands and
replay them to the tiled draw target on the paint thread when OMTP is enabled.
MozReview-Commit-ID: 22zL3c4NZvu
--HG--
extra : rebase_source : f8256b678da683da76edc02769dd4d0ebe234e09