UnregisterTextureOwner, if called before any use of UseRemoteTexture, can cause UseRemoteTexture to wait
for the texture owner to be created, since the texture owner does not exist, and there is no evidence it
was previously unregistered.
This patch attempts to address the issue by delaying the actual UnregisterTextureOwner until all such
UseRemoteTexture instances are processed. This is accomplished by noting that UseRemoteTexture ops come
in via transactions from a CompositableForwarder and so all are associated with a forwarder transaction
with a FwdTransactionId. RecordedTextureData on destruction reports the last FwdTransactionId associated
with its final UseRemoteTexture before it attempts to call UnregisterTextureOwner. If RemoteTextureMap
has not been notified of a given FwdTransactionId yet, then the UnregisterTextureOwner call will be
deferred until it has seen this FwdTransactionId.
This adds a RemoteTextureTxnScheduler to track the issuing of dependencies and waiting for FwdTransactionIds.
This patch also cleans up the issuing of FwdTransactionIds themselves to be associated with a given
top-level protocol so that all sub-protocols have transaction numbers that can be safely compared amongst
each other. This makes dependency expiration more robust since any advancement of the transaction number
from any source can help retire expired dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D197895
It's wasteful to call DrawTargetWebgl::BeginFrame if we're locking in a read-only mode. It may
also mess up DrawTargetWebgl's internal profiling if we count a read-only use as an actual frame.
Differential Revision: https://phabricator.services.mozilla.com/D197483
The idea of trying to obsolete the presented texture from the last frame when
creating a new texture, if we believe it wasn't used, seems problematic and
may not actually address the fundamental issue at hand.
It seems more like there are use-cases where the recorded texture is locked
and unlocked many times in succession, whereas we actually only intend to
present it once.
This decouples the TextureLock/TextureUnlock events from a new PresentTexture
event which handles the actual creation of remote texture ids, so that regardless
of how many times we lock/unlock the recorded texture, we don't actually churn
presentation unless we truly need to. This seems like a better way of addressing
the memory reuse issue than trying to remove textures since we don't create them
in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D197453
It looks like this was an oversight in bug 1155059, that in one place an
already_AddRefed does not get converted to a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D197374
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
ALLOC_MANUAL_SYNCHRONIZATION could be used only when ID3D11Texture2D is allocated by compositor device. But canvas device is not compositor device.
Differential Revision: https://phabricator.services.mozilla.com/D197276
It seems that locking has side-effect other than synchronization for
some backends, such as mapping data into readable/writeable memory. We
need to leave the lock calls in place, but so long as we leave
ALLOC_MANUAL_SYNCHRONIZATION in place for D2D, we will avoid created
a KeyedMutex which should still avoid synchronization overheads.
Meanwhile, incidental finding that a bug was caused by 1861605,
meaning KeyedMutexes stopped getting properly initialized in any case.
This fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D197271
When we use a TextureData instead of a DrawTargetWebgl, we manually register a remote
texture owner on CanvasTranslator's RemoteTextureOwnerClient. Unlike DrawTargetWebgl,
this client will stick around after the texture info goes away, so we need to also
manually unregister it when removing a texture id.
Differential Revision: https://phabricator.services.mozilla.com/D197264
This patch makes CanvasDrawEventRecorder track what eventCount we
recorded an external surface reference. When the reader has increment
its processedCount above that, we will release our reference as it
should have acquired a strong reference to the data. This was previously
done when we forwarded the texture, but with remote textures, we no
longer have this event. Now we check when we start a new recording, or
attempt to clear cached resources.
Differential Revision: https://phabricator.services.mozilla.com/D197216
This patch makes the CanvasManagerChild creates/manager the
ActiveResourceTracker instead of the WebRenderBridgeChild. Since PCanvas
is now managed by PCanvasManager, and ActiveResourceTracker is only used
by the PCanvas recording plumbing, we need it on every thread that the
CanvasManagerChild can be created.
Differential Revision: https://phabricator.services.mozilla.com/D189529
This patch adds/updates the thread assertion plumbing for CanvasChild
and DrawEventRecorder to ensure that we are always accessing them on the
owning thread. It also now makes these checks compatible with running in
a DOM worker context for OffscreenCanvas using recordings.
Differential Revision: https://phabricator.services.mozilla.com/D189526
This patch resolves a bunch of edge cases that may never happen,
but where we do not properly lock or unlock. It also adds more
critical notes in these cases so that we can better understand
texture locking failures.
Differential Revision: https://phabricator.services.mozilla.com/D196926
We can accumulate a bunch of waiting texture ids that never actually get
composited. By the time we go to lock a successive canvas frame, if nothing
has queried a surface descriptor for the preceding frame, it is safe to assume
that the canvas frame will never be rendered, since any record of its texture
id has been erased. In this case, we want to remove the resources allocated
to that texture immediately from the host side rather than let it sit around
indefinitely, in case no composition ever occurs.
Differential Revision: https://phabricator.services.mozilla.com/D196850
gecko uses IDXGIResource::GetSharedHandle(). But it is recommend not to use anymore to retrieve the handle to a shared resource.
IDXGIResource1::CreateSharedHandle() with D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag should be used instead of the GetSharedHandle().
The CreateSharedHandle() could be called only once for a shared resource. Later calls fail.
HANDLEs of ID3D11Texture2D are replaced by gfx::FileHandleWrappers.
Differential Revision: https://phabricator.services.mozilla.com/D192173
It is disabled in this patch via the gfx.canvas.remote.allow-offscreen
pref. A follow up patch will enable this by default.
Differential Revision: https://phabricator.services.mozilla.com/D189532
If ImageBridgeChild is responsible for the textures being forwarded to
the compositor process, then the callback will happen on
ImageBridgeChild's thread instead of the main or DOM worker thread.
Differential Revision: https://phabricator.services.mozilla.com/D195121
This patch makes the CanvasManagerChild creates/manager the
ActiveResourceTracker instead of the WebRenderBridgeChild. Since PCanvas
is now managed by PCanvasManager, and ActiveResourceTracker is only used
by the PCanvas recording plumbing, we need it on every thread that the
CanvasManagerChild can be created.
Differential Revision: https://phabricator.services.mozilla.com/D189529
This patch adds support for allocationg shmem sections for
ImageBridgeChild. The recording infrastructure depends on it.
Differential Revision: https://phabricator.services.mozilla.com/D189528
This patch adds/updates the thread assertion plumbing for CanvasChild
and DrawEventRecorder to ensure that we are always accessing them on the
owning thread. It also now makes these checks compatible with running in
a DOM worker context for OffscreenCanvas using recordings.
Differential Revision: https://phabricator.services.mozilla.com/D189526
If we fail to create CanvasChild::mRecorder, we shouldn't attempt to
readback a recording surface that never got created.
Differential Revision: https://phabricator.services.mozilla.com/D196767
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
There are some error paths where we could allocate an external image ID
for a SourceSurfaceSharedData before we are able to finish sharing it.
This patch makes it so that we defer allocating the ID until the last
possible moment. This will ensure they are always increasing in order.
The patch also adds in the necessary plumbing for notifications for
waking up threads blocked on a particular external image ID for a shared
surface inside the compositor process. This is less relevant now since
it should always been in the SharedSurfacesParent map, as recordings are
only created from the main thread, but may become more important as we
add recordings to DOM workers.
Differential Revision: https://phabricator.services.mozilla.com/D196422
Pixel 6, 7, and 8 devices running Android 14 are affected by a bug
where video frames with SMPTE 432 color primaries are rendered
incorrectly when sampled from an external texture in GLES. To work
around this, we force these frames to be converted to RGB using BT709
colorspace instead. While this won't look exactly right, it is much
better than the current situation.
When we detect that a frame is decoded with that color space on an
affected device, we set a "ForceBT709" flag which gets passed through
to webrender as a new ImageBufferKind. Rendering this ImageBufferKind
is handled via a new shader feature TEXTURE_EXTERNAL_BT709, which
works much like the existing TEXTURE_EXTERNAL feature, but
additionally uses the EXT_YUV_TARGET extension to override the
colorspace transformation.
This approach could be extended in the future to handle additional
colorspace transformations, but for now only handles the one required
to workaround this particular driver bug.
Differential Revision: https://phabricator.services.mozilla.com/D195800
Pixel 6, 7, and 8 devices running Android 14 are affected by a bug
where video frames with SMPTE 432 color primaries are rendered
incorrectly when sampled from an external texture in GLES. To work
around this, we force these frames to be converted to RGB using BT709
colorspace instead. While this won't look exactly right, it is much
better than the current situation.
When we detect that a frame is decoded with that color space on an
affected device, we set a "ForceBT709" flag which gets passed through
to webrender as a new ImageBufferKind. Rendering this ImageBufferKind
is handled via a new shader feature TEXTURE_EXTERNAL_BT709, which
works much like the existing TEXTURE_EXTERNAL feature, but
additionally uses the EXT_YUV_TARGET extension to override the
colorspace transformation.
This approach could be extended in the future to handle additional
colorspace transformations, but for now only handles the one required
to workaround this particular driver bug.
Differential Revision: https://phabricator.services.mozilla.com/D195800
