This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
We need to use the same visual for X drawable and glxContext,
otherwise we get BadMatch when we try to make the glxContext current.
The correct glx visual is already configured at nsWindow::Create()
so just use it if it also matches the frame buffer config.
MozReview-Commit-ID: 78IIfiwOnsf
--HG--
extra : rebase_source : 5ddfc0f94abafc7a1441eea095e546568bc31596
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 : c8f628180a3d908c8851e5c576296f903b9b255d
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 : 546d9838808320c51d9ceef0ed0ffcbb88a16269
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 : 2f63464c1f8ca03992700b33838c4aa56608f872
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 : efc838a3a4b196f78eda79ff3304c15d386bdc63
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 : 33a523e45f7102343ebd5b3aa1faf2ff1f3d6f87
This commit renames CapturedTiledPaintState to PaintTask as in a future
commit I will fold CapturedPaintState into it.
MozReview-Commit-ID: 8py7SrK4s29
--HG--
extra : rebase_source : 1b5259cca6520761ae99e64157d047441b90b563
This commit refactors TiledContentClient to not create PaintThread
buffer operations, but to instead perform all of these operations
on the DrawTarget(Capture). This simplifies the code dramatically
and allows us to add flushing behavior to DrawTargetCapture in a
future commit.
With this change, CapturedTiledPaintState is simply a container
for a DrawTarget, DrawTargetCapture, and keep-alive TextureClients.
Part of this commit is moving the logic of locking the texture
clients, constructing a dual draw target, and constructing a capture
into TiledContentClient so it can be shared.
MozReview-Commit-ID: 2rwz9aDI737
--HG--
extra : rebase_source : 16a4b87263f28b32f5bcb5fd6d9756548f137e11
This commit adds a RAII class for the common operation of attempting
to lock one or two TextureClients and then maybe constructing a
DrawTargetDual from them.
MozReview-Commit-ID: ECQkDSgpyuL
--HG--
extra : rebase_source : abad14bfee32ea2fd1626069f8229487d1f05015
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 : 47403847e56521be90190eb6b70ec333f6daf5c0
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 : ab850358a763853d50d1f374f28e67a197740443
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
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 renames CapturedTiledPaintState to PaintTask as in a future
commit I will fold CapturedPaintState into it.
MozReview-Commit-ID: 8py7SrK4s29
--HG--
extra : rebase_source : 7abdf127351cdc82ee4c40112dce7150bdb67243
extra : source : 01110727f2e9e0846fc06997653e04860efb23dc
This commit refactors TiledContentClient to not create PaintThread
buffer operations, but to instead perform all of these operations
on the DrawTarget(Capture). This simplifies the code dramatically
and allows us to add flushing behavior to DrawTargetCapture in a
future commit.
With this change, CapturedTiledPaintState is simply a container
for a DrawTarget, DrawTargetCapture, and keep-alive TextureClients.
Part of this commit is moving the logic of locking the texture
clients, constructing a dual draw target, and constructing a capture
into TiledContentClient so it can be shared.
MozReview-Commit-ID: 2rwz9aDI737
--HG--
extra : rebase_source : 4ac317f632c0a2c21480bc88e6246f4dc0daf0be
extra : source : 56d967e03ee225e032034ffd193b6f42b343226b
This commit adds a RAII class for the common operation of attempting
to lock one or two TextureClients and then maybe constructing a
DrawTargetDual from them.
MozReview-Commit-ID: ECQkDSgpyuL
--HG--
extra : rebase_source : 6debecb9d4ca33895daa78de3a52a1ed575706e1
extra : source : 082638a5c6432e0ca6ce377986d84ed130b32ad3
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
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 5c563ec8e388a3fd05a0650e8d4c330d48675332
Multiple tabs in the same process could be viewing the same image. If it
is an image we are taking some time to download from the network, it may
not be displayed all at once. As a result, it could generate several
dirty rects for the newly decoded lines each time we paint. Since we
only apply the dirty rect to the active tab, and forget it afterwards,
then when one returns to the other tab(s), it may not reupload all of
the modified image data. Now we save the dirty rect and accumulate it
for the handles which weren't able to be updated immediately.
The WebVR api was returning a headset pose predicted one additional frame in the
future, but the SteamVR async reprojection was reprojecting it using the
prior (correct) frame's pose.
This resulted in a sickness inducing swimming effect as well as deregistration
from the Vive chaperone bounds.
Differential Revision: https://phabricator.services.mozilla.com/D2693
--HG--
extra : moz-landing-system : lando
On Linux, when synthesizing mousemove events interleaved with button
press/release events, the caller is responsible for waiting for the
mousemove events be dispatched before attempting to synthesize the
press/release buttons, otherwise the events can be delivered by the OS
out of order. This updates a few tests to ensure this is done correctly.
MozReview-Commit-ID: 42HkqTCWToP
--HG--
extra : rebase_source : 57fbc84bcfbed345d8f6d90aaadb3399e691894e
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
When resuming composition in a new GeckoView, we wait for the first
paint signal in order to uncover the SurfaceView. This patch makes sure
that we always send the first paint signal.
MozReview-Commit-ID: EZeOR80d8HY
--HG--
extra : rebase_source : f82ab94ef87e5b0651f368918e8cd8a97469c68e
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
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
When masking as a secondary effect to RENDER_TARGET, mFBOTextureTarget
will have a target of GL_TEXTURE_2D, leading us to not use sampler2DRect
and friends for the mask. This fixes that, and also assures our coord
adjustments are based on the mask texture's dimensions.
MozReview-Commit-ID: JSDfDJuLNSa
--HG--
extra : rebase_source : 77010ae331f4d004e9b716e6063334d98529bf5f
Now that the shader problems are fixed it's a simple switch.
MozReview-Commit-ID: 6MJlEVITwii
--HG--
extra : rebase_source : cb33bd45196eca26476c52c2c50e51f03f6129f8
I'm not sure if there was a reason for not fully generalizing the
sampler2DRect and texture2DRect stuff throughout the shader
generalization file. It seemed the simplest thing was to fully
replace it - even if in some cases it doesn't make sense it's
more consistent, and it definitely fixes the trouble we were having
with switching to GL_TEXTURE_RECTANGLE_ARB for client storage.
MozReview-Commit-ID: 7243OjQdakN
--HG--
extra : rebase_source : 756741bbff4c56edec64cc6dd367328974b83b35
When masking as a secondary effect to RENDER_TARGET, mFBOTextureTarget
will have a target of GL_TEXTURE_2D, leading us to not use sampler2DRect
and friends for the mask. This fixes that, and also assures our coord
adjustments are based on the mask texture's dimensions.
MozReview-Commit-ID: JSDfDJuLNSa
--HG--
extra : rebase_source : c779b18789196c9352a862a17f4a1e8d799805ec
Now that the shader problems are fixed it's a simple switch.
MozReview-Commit-ID: 6MJlEVITwii
--HG--
extra : rebase_source : 7c91165633d5bc4fb07135781774998b0e1f1cf0
I'm not sure if there was a reason for not fully generalizing the
sampler2DRect and texture2DRect stuff throughout the shader
generalization file. It seemed the simplest thing was to fully
replace it - even if in some cases it doesn't make sense it's
more consistent, and it definitely fixes the trouble we were having
with switching to GL_TEXTURE_RECTANGLE_ARB for client storage.
MozReview-Commit-ID: 7243OjQdakN
--HG--
extra : rebase_source : d1b9f51f45d0cb875c82f3de5b2ea917e0385077
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 3e497f254ce91e4a8e539d475f90690831bcbe07
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 77613cbb99c14f19217592080bfd51ea2194422b
This restricts the active-item-detection code to wrap lists and
perspective items because other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 971de2c56d183090bb9a8701af62ada493e39b77
This restricts the active-item-detection code to wrap lists because
other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 5dbb8af8504f301ca49273b4f6f434a91524860a
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
When the layout viewport is smaller than the visual viewport and the user
scrolls a web page, the layout viewport remains fixed to its position before
the scroll event took place. However, the visual viewport moves according to
the new scroll position. This patch addresses this issue by moving the layout
viewport along with the visual viewport.
MozReview-Commit-ID: 3Mk1o6AF2wr
--HG--
extra : rebase_source : 8c6068059593038dc443cb9c96242483de97e9d9
When computing whether we have an intermediate buffer or not, which
in our case amounts to the inverse of deciding whether we want to use
a DirectMapTextureSource or not, we want to ensure that we don't use
one if the texture is too big to be a single texture in OpenGL. This
will default to using a TiledTextureImage. In a perfect world we
would build tiling logic into the client storage approach, but that
shouldn't block this.
MozReview-Commit-ID: 7Oi86oGis93
--HG--
extra : rebase_source : df9d314ef3d9a285bb10a9e21b87dc280a88fa84
This seems to be unused. Not sure if it's still left in here for
a reason or not.
MozReview-Commit-ID: 3wxaCDI7eCO
--HG--
extra : rebase_source : 25dda76dce892e580dbf31741e359d3a78f5742a
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
This patch will use DirectMapTextureSource to wrap the DataSourceSurface data for gpu access.
That could improve the texture uploading performance.
MozReview-Commit-ID: CGPFcCsR1RY
--HG--
extra : rebase_source : fd0e5076357d8893e9283930fc4d6fb944a3f1de
The client side can't get the GL context in CompositorOGL. So, it can't know
the texture direct mapping capability directly. This patch adds the texture
direct mapping info in TextureFactoryIdentifier. Then, the client side could
get the info form the TextureFactoryIdentifier.
MozReview-Commit-ID: KEazDVg0p9Y
--HG--
extra : rebase_source : 09ce1065cd076a3a5dc276f93837d608443c60a1
The DirectMapTextureSource could let the compositor to read the buffer directly.
That could get rid of some memory copy operations during texture uploading.
MozReview-Commit-ID: CHhoR96P7VG
--HG--
extra : rebase_source : 65c167644096a1b72fe5dfbb55837842f41377bb
The "mExternallyOwned" is used for gralloc buffer. We don't use the gralloc buffer now.
MozReview-Commit-ID: 7Gurpa3kdp0
--HG--
extra : rebase_source : 5c0bf4facba5ed2cc8772df78bb702965e77a4ab
The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
This adds a WEBRENDER_QUALIFIED feature that's set whenever the webrender could
be used on a machine regardless of whether it's actually being used.
MozReview-Commit-ID: Eke6PMKQOnx
--HG--
extra : rebase_source : 977d371c12c9e8ab3273d6e65655e0378c22c226
Without KeyedMutex we use glFinish, which is bad.
We accidentally stopped asking ANGLE for KeyedMutexes during some build changes.
Differential Revision: https://phabricator.services.mozilla.com/D2084
--HG--
extra : moz-landing-system : lando
This change has WrClipId contain the ClipId type (except for clip
chains, which are handled separately) in the least significant bit of
the size_t. On 32-bit systems this limits the number of clip and spatial
nodes to 2,147,483,648 which is likely more than what WebRender can
handle.
MozReview-Commit-ID: 1cpZCBt1wL7
--HG--
extra : rebase_source : 8183570e37bf6da69a3e7335d63fc47cad191fe9
This commit ports over the last remaining operation for tiling that doesn't work
on the paint thread.
The difficult part for edge padding is that it is done outside of ValidateTile
so it doesn't have an associated CapturedTilePaintState to be added to as an
operation. We need it to be in the same paint state so that it's guaranteed
to be run after painting has finished.
This commit changes edge padding to instead be decided inside of ValidateTile
and either sent to the paint thread if there is OMTP or executed right away.
MozReview-Commit-ID: JDD4rH1fVwW
--HG--
extra : source : 9b0a54842d3169960a606fa1dd335acf6aa70dbe
extra : intermediate-source : bcbab66c16c5cc2b917f12b4481bbbb8fe3eb097
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
Added a data member to nsIPresShell to store the visual viewport offset. APZ
will update the visual viewport offset in the presShell for root scroll frames
on every repaint request.
MozReview-Commit-ID: Ksou43hrE6H
--HG--
extra : rebase_source : 812c88efc7556c4bff2a62834cfaaec6e6945093
This change has WrClipId contain the ClipId type (except for clip
chains, which are handled separately) in the least significant bit of
the size_t. On 32-bit systems this limits the number of clip and spatial
nodes to 2,147,483,648 which is likely more than what WebRender can
handle.
MozReview-Commit-ID: 8ohMKqTZcKT
--HG--
extra : rebase_source : cce763be7c0637bf97e96c23f8dba5aeff34baaf
There is a race between when APZ is made aware of a main thread change to a
frame's overflow property and when it decides whether to allow scrolling in
response to an input event. If the processing of the input event wins the race,
APZ can allow scrolling an element that has recently been made overflow:hidden.
The main thread previously asserted about the attempt to scroll an
overflow:hidden element, but since this can occur in practice, is relatively
benign, and is hard to avoid, we will now allow it.
MozReview-Commit-ID: IkH7xWyMOEl
--HG--
extra : rebase_source : 9d5ca0986979ba570f8cab481ac9da5eed43f35a
sotaro
Ryan VanderMeulen
Daniel Varga
Myk Melez
Jeff Muizelaar
Imanol Fernandez
L. David Baron
Botond Ballo
Tiberius Oros
Martin Stransky
Jonathan Kew
Bas Schouten
Nathan Froyd
Kartikaya Gupta
Jeff Gilbert
Brindusan Cristian
Ryan Hunt
Gabriele Svelto
Noemi Erli
Jan Beich
Andi-Bogdan Postelnicu
Masatoshi Kimura
Andrew Osmond
Lee Salzman
Kearwood "Kip" Gilbert
ISHIKAWA, Chiaki
Bogdan Tara
Narcis Beleuzu
Cosmin Sabou
Brian Hackett
Boris Zbarsky
Nicolas Silva
David Major
Randall Barker
Xidorn Quan
Jim Chen
Hiroyuki Ikezoe
Coroiu Cristina
Jamie Nicol
Imanol Fernandez
Gurzau Raul
Mitch Ament
Doug Thayer
Andreea Pavel
Dorel Luca
Csoregi Natalia
Thomas P.
Emilio Cobos Álvarez
Sebastian Hengst
Mike Hommey
Kris Maglione
Tanushree Podder
Robert Longson
Miko Mynttinen
Robert Bartlensky
Margareta Eliza Balazs
shindli
Martin Robinson
Kashav Madan
Sylvestre Ledru
Matt Woodrow
Alexis Beingessner
Andrea Marchesini
Ciure Andrei