This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
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
Because we cannot control the ordering of shutdown notification from
WorkerRef, we need to choose one centralized point to begin shutdown of
the main thread or the owning DOM worker. Since there are other objects
owned by CanvasManagerChild, we also switch to a ThreadSafeWorkerRef.
Differential Revision: https://phabricator.services.mozilla.com/D195120
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
Because we cannot control the ordering of shutdown notification from
WorkerRef, we need to choose one centralized point to begin shutdown of
the main thread or the owning DOM worker. Since there are other objects
owned by CanvasManagerChild, we also switch to a ThreadSafeWorkerRef.
Differential Revision: https://phabricator.services.mozilla.com/D195120
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
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
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
DrawTargetWebgl is transitioning away from using ClientWebGLContext, so
local extensions that were added to support that use-case are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D194346
When we call IDXGIKeyedMutex::AcquireSync, we need to check for a
general failure, WAIT_ABANDONED and WAIT_TIMEOUT. The last two are
special because Microsoft's SUCCEEDED and FAILED macros consider them
successful.
Differential Revision: https://phabricator.services.mozilla.com/D196668
Ideally we'd check whether we are using mesa, but we have to make the decision before creating the context and need the latter to know whether mesa is involved.
Differential Revision: https://phabricator.services.mozilla.com/D193053
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
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
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
DrawTargetWebgl is transitioning away from using ClientWebGLContext, so
local extensions that were added to support that use-case are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D194346
This patch makes it so that WebGL that runs in the compositor process
can take advantage of the fact that GPUVideoImage should have an already
created TextureHost between the compositor process and the producing
utility process. For software decoders, this will allow us to avoid a
copy into a shmem from the utility process, and another copy into a
shmem to the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D195559
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
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
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
DrawTargetWebgl is transitioning away from using ClientWebGLContext, so
local extensions that were added to support that use-case are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D194346
Mostly drive-by. Hide macOS specific colors from content, and also the native
hyperlinktext color, which isn't and shouldn't be used from CSS at all.
Differential Revision: https://phabricator.services.mozilla.com/D195296