This uses existing gl math to do colorSpace conversion between
predefined DOM colorSpaces (sRGB and Display P3). It does not yet
accurately read the inbound colorSpace of the image -- it just assumes
it is sRGB.
Differential Revision: https://phabricator.services.mozilla.com/D218362
GL_EXT_semaphore and GL_EXT_semaphore_fd are used to import Vulkan semaphores into OpenGL from POSIX file descriptor external handles.
Differential Revision: https://phabricator.services.mozilla.com/D220978
Add the capability to transform the texture coordinates when reading
from a texture, similar to existing support in GLBlitHelper and
CompositorOGL.
This patch doesn't change any behaviour, but this capability will be
made use of by a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220580
Add the capability to transform the texture coordinates when reading
from a texture, similar to existing support in GLBlitHelper and
CompositorOGL.
This patch doesn't change any behaviour, but this capability will be
made use of by a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D220580
Android SurfaceTextures provide a transform that should be applied to
texture coordinates when rendering. Usually this is simply a y-flip,
but not always. While we handle the transform correctly in our regular
rendering path, GLBlitHelper (used for example when using a video as a
webgl texture) currently hard-codes a y-flip. This patch replaces the
hardcoded y-flip with the provided transform.
Differential Revision: https://phabricator.services.mozilla.com/D218834
With NVIDIA GPU, original ID3D11Texture2D created by compositor device and ID3D11Texture2D opened from shared handle compositor device seemed to work differently. The original ID3D11Texture2D seemed to work well with STR of Bug 1911237 with NVIDIA GPU.
Then if ID3D11Texture2D is created by compositor device, it seems better to use GpuProcessTextureId instead of shared handle.
Differential Revision: https://phabricator.services.mozilla.com/D218903
willReadFrequently already implies this; however that can't
be enabled on Windows. We can use our own attribute to control
the value as it plumbs into the depths of Canvas2D and WebGL
Differential Revision: https://phabricator.services.mozilla.com/D212178
Adds a pref wegb.enable-egl-image which is true by default. When
enabled, we use EGL images as the preferred texture type for
out-of-process webgl and accelerated canvas on Android. In-process
webgl will never attempt to use EGL images, regardless of the value of
the pref, as we are unable to send EGL images cross-process.
Differential Revision: https://phabricator.services.mozilla.com/D211293
SharedSurface_EGLImage has mostly avoided bitrotting. However, it now
sometimes gets destructed after the GLContext has been lost, resulting
in a crash when attempting to clean up its resources. To avoid this,
we hold a weak reference to the EglDisplay, and use that to clean up
rather than the GLContext.
To support rendering with SWGL, EGLImageTextureHost ensures the
correct preferCompositorSurface, supportsExternalCompositing, and
imageType values are sent to webrender. RenderEGLImageTextureHost now
implements RenderTextureHostSWGL, as well as the new
CreateTextureSource() function, and EGLImageTextureSource is
initialized with a GL context reference so that it may actually work.
Additionally we use eglWaitSync() rather than eglClientWaitSync()
where available for improved performance. And we ensure that we bind
the EGL images' textures to GL_TEXTURE_2D rather than
GL_TEXTURE_EXTERNAL when running on the Android emulator to work
around the buggy implementation in some emulator versions.
Differential Revision: https://phabricator.services.mozilla.com/D211291
Adds a pref wegb.enable-egl-image which is true by default. When
enabled, we use EGL images as the preferred texture type for
out-of-process webgl and accelerated canvas on Android. In-process
webgl will never attempt to use EGL images, regardless of the value of
the pref, as we are unable to send EGL images cross-process.
Differential Revision: https://phabricator.services.mozilla.com/D211293
SharedSurface_EGLImage has mostly avoided bitrotting. However, it now
sometimes gets destructed after the GLContext has been lost, resulting
in a crash when attempting to clean up its resources. To avoid this,
we hold a weak reference to the EglDisplay, and use that to clean up
rather than the GLContext.
To support rendering with SWGL, EGLImageTextureHost ensures the
correct preferCompositorSurface, supportsExternalCompositing, and
imageType values are sent to webrender. RenderEGLImageTextureHost now
implements RenderTextureHostSWGL, as well as the new
CreateTextureSource() function, and EGLImageTextureSource is
initialized with a GL context reference so that it may actually work.
Additionally we use eglWaitSync() rather than eglClientWaitSync()
where available for improved performance. And we ensure that we bind
the EGL images' textures to GL_TEXTURE_2D rather than
GL_TEXTURE_EXTERNAL when running on the Android emulator to work
around the buggy implementation in some emulator versions.
Differential Revision: https://phabricator.services.mozilla.com/D211291
willReadFrequently already implies this; however that can't
be enabled on Windows. We can use our own attribute to control
the value as it plumbs into the depths of Canvas2D and WebGL
Differential Revision: https://phabricator.services.mozilla.com/D212178
willReadFrequently already implies this; however that can't
be enabled on Windows. We can use our own attribute to control
the value as it plumbs into the depths of Canvas2D and WebGL
Differential Revision: https://phabricator.services.mozilla.com/D212178
In bug 1868825 we encountered crashes on a specific device when
calling eglTerminate. As a workaround, we avoided calling eglTerminate
and instead deliberately leaked the EGLDisplay. As we had only
encountered this crash on a specific device, we limited the workaround
to just that device.
We are now seeing the same crash on a range of devices, all with
Samsung Xclipse GPUs. This patch therefore makes us leak the
EGLDisplays on all devices with an Xclipse GPU.
As the GPU model is not available in EglDisplay code, we instead set a
flag on the EglDisplay object when the GLContext is initialized. Prior
to terminating the display we check whether this flag has been set.
Terminating a display which has not had a context created does not
reproduce the crash, so this is sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D214539
D3D11YCbCrImage class is no longer used.
But DXGIYCbCrTextureAllocationHelper and D3D11YCbCrRecycleAllocator in D3D11YCbCrImage.h are still used.
Differential Revision: https://phabricator.services.mozilla.com/D213383
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
Brad Werth
sotaro
Jamie Nicol
Iulian Moraru
Kelsey Gilbert
Tom Ritter
Sylvestre Ledru
Cristian Tuns
Sandor Molnar
Stanca Serban
Lee Salzman
stransky
Mike Hommey
Narcis Beleuzu
Steve Fink
Cosmin Sabou
Jeff Muizelaar