The gfxPlatform::GetScreen* methods have always been redundant. Removing
them in favor of ScreenManager or nsDeviceContext methods will
discourage future code authors from adding more redundancy in
gfxPlatform.
Differential Revision: https://phabricator.services.mozilla.com/D203672
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
By default, hardware video decoder uses compositor device for D3D11Device. In this case, mSyncObject->Synchronize() in RenderCompositorANGLE::BeginFrame() is not necessary.
When ID3D11Texture2D is created by compositor device, the Synchronize() is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D201693
This reverts commit e25a5f344af32bdd689500bae7b4f24f205ba9f0.
We believe bug 1664063 was causing to hit some broken device reset
handling code.
Differential Revision: https://phabricator.services.mozilla.com/D201658
We have reports of the same flickering that we were seeing on
Xclipse920 GPUs on Xclipse940. For now, let's just enable the workaround
on all Xclipse GPUs.
Differential Revision: https://phabricator.services.mozilla.com/D200944
Normally when D3D11Texture2D is copied by ID3D11DeviceContext::CopySubresourceRegion() with compositor device, WebRender does not need to wait copy complete, since WebRender also uses compositor device.
But with Non-intel GPUs(like NDIVIA), there is a case that the copy complete need to be wait explicitly even with compositor device
mSyncObject->Synchronize() could not be used with compositor device.
Wait of the query is not called in D3D11DXVA2Manager::CopyToImage(), since the wait could take long time. Then the Wait of the query is deferred to just before blitting for video overlay.
Differential Revision: https://phabricator.services.mozilla.com/D200041
It looks like we're accidentally putting SharedSurfaces that came from a different
SurfaceFactory back into a different one recycling. This happens because on context
loss in CanvasTranslator, the old GL context may go away, though the RemoteTextureOwnerClient
has a shared recycling bin that might accidentally keep the old surfaces.
This also tries to clear the old recycled surfaces as soon as possible on a context
loss now.
Differential Revision: https://phabricator.services.mozilla.com/D198918
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
On a given thread, if there are outside users of OpenGL (such as WebRender) that don't go
through the GLContext interface to set the current context, the TLS current context value
may be incorrect. To solve this, we need to assume that on establishing some TLS scopes,
that the current context value is unreliable and invalidate it so that it gets properly
reset.
Differential Revision: https://phabricator.services.mozilla.com/D194350
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
In CompositorOGL (used by software webrender on Android) as an
optimization we use glInvalidateFramebuffer rather than glClear for
the color attachment if there is no non-opaque invalid region. This
causes rendering glitches on the Samsung Xclipse 920 GPU. This patch
marks GLfeature::invalidate_framebuffer as unsupported on this GPU,
causing us to fall back to the glClear pach which avoids the glitches.
Differential Revision: https://phabricator.services.mozilla.com/D196416
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
We are seeing crashes on the european Samsung S22 family of devices in
eglTerminate after updating to Android 14. To work around this we
deliberately leak the EGLDisplay on affected devices. In practice we
only ever use the default EGLDisplay on Android, and calling
eglInitialize multiple times is allowed, so this is fine.
Note this only occurs when running webgl in the content process, which
will occur naturally following enough GPU process crashes that we
disable the GPU process. When webgl is running in the GPU process
webrender keeps the EGLDisplay alive, meaning we never terminate it.
Differential Revision: https://phabricator.services.mozilla.com/D196146
We are seeing crashes on the european Samsung S22 family of devices in
eglTerminate after updating to Android 14. To work around this we
deliberately leak the EGLDisplay on affected devices. In practice we
only ever use the default EGLDisplay on Android, and calling
eglInitialize multiple times is allowed, so this is fine.
Note this only occurs when running webgl in the content process, which
will occur naturally following enough GPU process crashes that we
disable the GPU process. When webgl is running in the GPU process
webrender keeps the EGLDisplay alive, meaning we never terminate it.
Differential Revision: https://phabricator.services.mozilla.com/D196146
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
On a given thread, if there are outside users of OpenGL (such as WebRender) that don't go
through the GLContext interface to set the current context, the TLS current context value
may be incorrect. To solve this, we need to assume that on establishing some TLS scopes,
that the current context value is unreliable and invalidate it so that it gets properly
reset.
Differential Revision: https://phabricator.services.mozilla.com/D194350
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
On a given thread, if there are outside users of OpenGL (such as WebRender) that don't go
through the GLContext interface to set the current context, the TLS current context value
may be incorrect. To solve this, we need to assume that on establishing some TLS scopes,
that the current context value is unreliable and invalidate it so that it gets properly
reset.
Differential Revision: https://phabricator.services.mozilla.com/D194350
In current gecko, SharedSurface_ANGLEShareHandle requests ANGLE to allocate ID3D11Texture2D. But Bug 1865984 and Bug 1861605 requests to change D3D11_TEXTURE2D_DESC::MiscFlags. To do it, the ID3D11Texture2D needs to be allocated by SharedSurface_ANGLEShareHandle.
Differential Revision: https://phabricator.services.mozilla.com/D194332
