зеркало из https://github.com/mozilla/gecko-dev.git
ada9a43cc2
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 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| docs | ||
| forms | ||
| generic | ||
| inspector | ||
| ipc | ||
| mathml | ||
| media | ||
| painting | ||
| printing | ||
| reftests | ||
| style | ||
| svg | ||
| tables | ||
| tools | ||
| xul | ||
| moz.build | ||