glFenceSync/glClientWaitSync just seem to be more well supported
on nvidia hardware, and they work fine as well on AMD/intel, so
I'm transitioning to that.
Depends on D6463
Differential Revision: https://phabricator.services.mozilla.com/D6464
--HG--
extra : moz-landing-system : lando
- Implemented 1ms, 10ms, and 100ms VR tasks, dispatched from
VRManager
- Removed Android-specific code that compensated for
tasks that did not run when the...
...compositor was paused.
Differential Revision: https://phabricator.services.mozilla.com/D3378
--HG--
extra : moz-landing-system : lando
Prevent future ambiguous conversion once a bit depth int is added.
Also more self-explanatory
Differential Revision: https://phabricator.services.mozilla.com/D6662
--HG--
extra : moz-landing-system : lando
This patch enables the compositor process memory reporting for both the
dedicated GPU process case, and the integrated with the main process
case. This will simply cause us to list all of the entries in the shared
surfaces cache to show what is presently mapped in.
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
This exposes methods to capture a snapshot of the SharedSurfacesParent
cache for memory reporting purposes. It yields the identifiers, image
properties and references to images mapped in the cache. This will be
used by the compositor process to list everything it has mapped into its
memory space. It will also be used by the content processes / main
process to list images that specific process had mapped into the
compositor process. This will allow us to easily identify what images
remain in the compositor process, but are missing from the surface
cache.
The texture client bound in a GPUVideoImage can be destroyed underneath
it if the GPU process crashed and was restarted. This is because the
ImageBridgeChild singleton will destroy any textures bound to it before
reinitializing itself. If there is a race to access a now stale
GPUVideoImage object, we could accidently dereference the underlying
TextureData which is now null in the TextureClient which was kept alive
in the GPUVideoImage object. Now we check to make sure the TextureData
is still there before accessing.
This allows us to invalidate individual items inside of the mask instead of
treating the mask and it's children as a single item.
Differential Revision: https://phabricator.services.mozilla.com/D6224
It isn't possible to trigger this code currently because
the only way to have an inactive 3d transform is with a mask
or filter item and those get handled with a BasicLayerManager.
This becomes necessary once we handle mask items internally.
Differential Revision: https://phabricator.services.mozilla.com/D6222
As explained in the bug, it has been difficult ot find reliable STR for
the diagnostic assert, and it has been impacting the stability and usability
of Nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D6518
--HG--
extra : moz-landing-system : lando
It's possible to trigger this assertion with asyncPaint = true and
bufferRotation != (0, 0). In this case though everything should work fine,
because we didn't start a new paint task, and we should be able to copy over
buffers. So we should be able to remove this assertion.
--HG--
extra : amend_source : d4cb9eddf48e08446469d2e1891f0e9ed3bb85d0
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
