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
Ryan Hunt
Gabriele Svelto
sotaro
Noemi Erli
Jan Beich
Andi-Bogdan Postelnicu
Masatoshi Kimura
Andrew Osmond
Lee Salzman
Kearwood "Kip" Gilbert
ISHIKAWA, Chiaki
Bogdan Tara
Kartikaya Gupta
Narcis Beleuzu
Cosmin Sabou
Brian Hackett
Boris Zbarsky
dvarga
Nicolas Silva
Jonathan Kew
David Major
Randall Barker
Xidorn Quan
Jim Chen
Hiroyuki Ikezoe
Imanol Fernandez
Coroiu Cristina
Jamie Nicol
Imanol Fernandez
Gurzau Raul
Mitch Ament
Jeff Gilbert
Doug Thayer
Andreea Pavel
Dorel Luca
Csoregi Natalia
Thomas P.
Emilio Cobos Álvarez
Jeff Muizelaar
Sebastian Hengst
Tiberius Oros
Mike Hommey
Nathan Froyd
Kris Maglione
Brindusan Cristian
Tanushree Podder
Robert Longson
Ryan VanderMeulen
Miko Mynttinen