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
In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
Ensures that APZ correctly updates the layout viewport offset when the visual
viewport exceeds the boundaries of the layout viewport.
Includes changes to APZCPinchTester::GetPinchableFrameMetrics to correct the
offset of the composition bounds (which should always be (0, 0) for the
RCD-RSF) and fixes to impacted test cases.
MozReview-Commit-ID: I3hTx9kCjEP
--HG--
extra : rebase_source : 0758399565d0086f8dc7d56881d912dbc0560a04
There are 3 main components to this change:
a) Store the origin of the layout viewport in APZ (until now we only stored
it's size). This required updating the offset stored in mViewport, which
was previously (0, 0).
b) Adjust the layout viewport in APZ each time the visual viewport exceeds
the bounds of the layout viewport.
c) Update the main thread to store the layout viewport offset for the
RCD-RSF (currently it uses the layout viewport offset for overflow:hidden
pages, and the visual viewport offset otherwise).
MozReview-Commit-ID: 7AD8wvthh2m
--HG--
extra : rebase_source : df8704146740f4b2522c80b20b603617993b6c83
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
In the case of an invalid clip-path, the browser is supposed to discard the
mask entirely. In the non-webrender codepath this would happen
implicitly because the computed MaskUsage would have no flags set, and
so no actions would be taken on the gfxContext which contained the
display items rasterized so far. In the WebRender codepath, though, we
invoke the code on a A8 drawtarget that's zero-filled, so if PaintMask
fails to rasterize anything into it, it gets treated as a "mask everything
out" mask. Instead, this patch makes it so that we detect the scenario
where the computed MaskUsage is a no-op, and ensure that we don't apply
the mask in that case.
An alternative approach considered was to initialize the A8 drawtarget to
white instead of black but in cases where there is an actual mask, the
rest of the code assumes it is zero-filled and so that doesn't work.
MozReview-Commit-ID: Hw7nCiUXVJl
--HG--
extra : rebase_source : 241d550fa0ed1b3bd088c73d9565b166acbcece8
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 : 3624ad04aa01dac1cd38efb47764dc3a8fbd5fbd
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 : 750cc82f0de01289ee261e8d338cd7ea39a2e4c5
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 : 1d7c0700d1f24236102de467efd84af093687ab5
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 : fbca3bd3b8af29939626e697909cc67e9a5b34cc
The "mExternallyOwned" is used for gralloc buffer. We don't use the gralloc buffer now.
MozReview-Commit-ID: 7Gurpa3kdp0
--HG--
extra : rebase_source : 00d74c0bc8e8e164571e05942768cf18d9cbce4d
- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : 973253589d6c27138bd49f4d81b3e74c3fcf5022
extra : histedit_source : 5b126b0285b674d59d8bd4b7bda09a01804dc043
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : 29ebd6a85dd49ee263d50e3674eec4957ac5f12a
extra : histedit_source : 1aa9f4f31b5bff6736e0c0e576a5611880d0ab33
This commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 97b0a86c4a2905d098ab199d6d1a1fd00c58a46d
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : acbf83d0071e8932b5e96016e6e39e27a7b4da8c
extra : histedit_source : a0f93f80441e5f45c0113244d15400d0f53d9c92
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : cecb7149f50b2abe7a827dc20f1e8b8ade199258
extra : histedit_source : 581f8f38fc8335575d7275b903a8e1d6a9e5a369
This commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 8ecb1f9146376ac84b84680a5a3454200c940d6a
VSync on Wayland is a bit tricky as we can get only "last VSync" event signal with
CLOCK_MONOTONIC timestamp or none (if application is hidden/minimized).
That means we should draw a next frame at "last Vsync + frame delay" time and also
approximate next VSync event when we don't get any.
MozReview-Commit-ID: FI3Z4nkmDNK
--HG--
extra : rebase_source : 8a0f6148990cf4e7ad26ff287eadff87cb0215fc
This was missed when the residual offset was added; it's correctly checked elsewhere
MozReview-Commit-ID: 44N5vDWLBIo
--HG--
extra : rebase_source : 37b42b8df416638e84531ed088c29716e4446159
Kearwood "Kip" Gilbert
ISHIKAWA, Chiaki
Bogdan Tara
Lee Salzman
Kartikaya Gupta
Narcis Beleuzu
Cosmin Sabou
Brian Hackett
Masatoshi Kimura
Boris Zbarsky
Noemi Erli
dvarga
Nicolas Silva
Jonathan Kew
David Major
Randall Barker
sotaro
Xidorn Quan
Jim Chen
Hiroyuki Ikezoe
Imanol Fernandez
Coroiu Cristina
Jamie Nicol
Imanol Fernandez
Gurzau Raul
Mitch Ament
Jeff Gilbert
Ryan Hunt
Doug Thayer
Andreea Pavel
Jan Beich
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
Robert Bartlensky
Margareta Eliza Balazs
shindli
Martin Robinson
Kashav Madan
Bas Schouten
Sylvestre Ledru
Matt Woodrow
Alexis Beingessner
Andrea Marchesini
Ciure Andrei
Jan de Mooij
Jacek Caban
Boris Chiou
Andi-Bogdan Postelnicu
Andrew Osmond
jgilbert@mozilla.com
arthur.iakab
James Willcox
Martin Stransky