Bug 1652894 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I experimented with returning a `WrExternalImageType::RawData` from `Lock`, the idea was to pass raw bytes from a locked surface; but ran into [some resistance](https://searchfox.org/mozilla-central/source/gfx/wr/webrender/src/renderer.rs#5681) in WR.  It's really set up to expect a valid GL texture handle.

Lacking a valid GLContext under SWGL, a low friction cheat is to directly call SWGL functions inside `CreateTextureForPlane`, to make said texture handle:

```cpp
extern "C" {
    void GenTextures(int n, GLuint* result);
    void TexParameteri(GLenum target, GLenum pname, GLint param);
    // ...
}

if (!aGL) {
 ::GenTextures(1, aTexture); 
 ::ActiveTexture(LOCAL_GL_TEXTURE0);
 ::BindTexture(LOCAL_GL_TEXTURE_RECTANGLE_ARB, *aTexture);
 ::PixelStorei(GL_UNPACK_ROW_LENGTH, aSurface->GetBytesPerRow(aPlaneID));
 void* rgba_data = aSurface->GetBaseAddressOfPlane(aPlaneID);
 ::TexImage2D(LOCAL_GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA,
        aSurface->GetWidth(), aSurface->GetHeight(), 0, GL_RGBA, GL_UNSIGNED_BYTE, rgba_data);
  // ...
```

This could work if the aSurface was guaranteed RGBA, eg. after baking YUV to RGBA on the CPU.

However,
1. the plane locking is in webrender_bindings/ but SWGL is in wr/ so technically that API is not available, I think?
2. same for `CreateSourceSurfaceFromMacIOSurface` if we wanted to use it for YUV->RGBA?
3. the crash is in YUV compositor; giving it RGBA data won't work right, but giving it YUV data won't work either due to missing support for the right internal_formats ? I think?  We'd have to decide which we way we want to go, as Markus said.

I'll continue investigating.
I experimented with returning a `WrExternalImageType::RawData` from `Lock`, the idea was to pass raw bytes from a locked surface; but ran into [some resistance](https://searchfox.org/mozilla-central/source/gfx/wr/webrender/src/renderer.rs#5681) in WR.  It's really set up to expect a valid GL texture handle.

Lacking a valid GLContext under SWGL, a low friction cheat is to directly call SWGL functions inside `CreateTextureForPlane`, to make said texture handle:

```cpp
extern "C" {
    void GenTextures(int n, GLuint* result);
    void TexParameteri(GLenum target, GLenum pname, GLint param);
    // ...
}

if (!aGL) {
 ::GenTextures(1, aTexture); 
 ::ActiveTexture(LOCAL_GL_TEXTURE0);
 ::BindTexture(LOCAL_GL_TEXTURE_RECTANGLE_ARB, *aTexture);
 ::PixelStorei(GL_UNPACK_ROW_LENGTH, aSurface->GetBytesPerRow(aPlaneID));
 void* rgba_data = aSurface->GetBaseAddressOfPlane(aPlaneID);
 ::TexImage2D(LOCAL_GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA,
        aSurface->GetWidth(), aSurface->GetHeight(), 0, GL_RGBA, GL_UNSIGNED_BYTE, rgba_data);
  // ...
```

This could work if the aSurface was guaranteed RGBA, eg. after baking YUV to RGBA on the CPU.

However,
1. the plane locking is in webrender_bindings/ but SWGL is in wr/ so technically that API is not available, I think?
2. same for `CreateSourceSurfaceFromMacIOSurface` if we wanted to use it for YUV->RGBA?
3. the crash is in YUV compositor; giving it RGBA data won't work right, but giving it YUV data won't work either due to missing support for the right internal_formats ? I think?  We'd have to decide which way we want to go, as Markus said.

I'll continue investigating.

Back to Bug 1652894 Comment 5