Fix CHROMIUM image APIs. |
|||
Issue descriptionCreateImageCHROMIUM takes an "internalformat" parameter. This doesn't make any sense, since many consumers of CreateImageCHROMIUM never need to bind the image to a texture, and if they do, they can specify "internalformat" during the Bind call. This means that when ResourceProvider::LazyCreateImage calls CreateImageCHROMIUM, it needs to make up an "internalformat", even though the result may never be bound to a texture. The function GLInternalFormat() gets used to maps from (cc::ResourceFormat "format" -> GLenum "internalformat"). The result is that ResourceProvider sends GL_BGRA as the "internalformat" to CreateImageCHROMIUM [for IOSurfaces on Mac], which is nonsense. See https://bugs.chromium.org/p/chromium/issues/detail?id=595948#c4 for my proposed API changes.
,
Mar 28 2016
Sounds like a problem in the compositor rather than a problem with the CHROMIUM_image extension. Can we just fix the compositor? CHROMIUM_image is based on the equivalent EGL image extensions (EGL_KHR_image_base [1], OES_EGL_image_external [2], etc.) and has been structured to match them as closely as possible. I think we should keep that design. The internalformat is specified when creating an image and not when binding it to a texture when using these extensions. [1] https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt [2] https://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt
,
Apr 8 2017
erikchen: did reveman's answer address this, or is there more to do?
,
Apr 11 2017
There's nothing I'd like to do at this point in time. |
|||
►
Sign in to add a comment |
|||
Comment 1 by erikc...@chromium.org
, Mar 25 2016