[webkit-reviews] review granted: [Bug 209139] [ iOS wk2 ] webgl/1.0.3/conformance/textures/copy-tex-image-2d-formats.html is failing. : [Attachment 412260] Patch

[bugzilla-daemon at webkit.org]

Dean Jackson <dino at apple.com> has granted Kenneth Russell <kbr at google.com>'s
request for review:
Bug 209139: [ iOS wk2 ]
webgl/1.0.3/conformance/textures/copy-tex-image-2d-formats.html is failing.
https://bugs.webkit.org/show_bug.cgi?id=209139

Attachment 412260: Patch

https://bugs.webkit.org/attachment.cgi?id=412260&action=review




--- Comment #19 from Dean Jackson <dino at apple.com> ---
Comment on attachment 412260
  --> https://bugs.webkit.org/attachment.cgi?id=412260
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=412260&action=review

>> Source/WebCore/platform/graphics/angle/ExtensionsGLANGLE.cpp:610
>> +	if (!readingToPixelBufferObject && !attrs.alpha && (format ==
GraphicsContextGL::RGBA || format == GraphicsContextGL::BGRA) && (type ==
GraphicsContextGL::UNSIGNED_BYTE) && (state.boundReadFBO == m_context->m_fbo ||
(attrs.antialias && state.boundReadFBO == m_context->m_multisampleFBO)))
> 
> Out of curiosity, did we not want to extend ANGLE workarounds around this
area instead of existing more unstructured workarounds? Or would this be more
task for downstream core developers? 
> 
> It'd help maybe making  this more perfect in cases like
preserveDrawingBuffer, which probably shouldn't need the workaround on grounds
of the backing being normal texture instead of an iosurface
> I guess part of the tedious work would be to understand what's the root cause
of the problem.
> 
> I did a bit of similar work in https://bugs.webkit.org/show_bug.cgi?id=215804
but it's not finished due to not being that important. It might or might not be
same root cause but different trigger this time. E.g. in that bug, glclear is
"buggy", but it might be that BlitFramebuffer is buggy. So in this case, it
might be that read pixels work but then rendering from blitted-to texture would
be black. Anyhow, this is an tangent to the actual question wrt do we want the
fix eventually in ANGLE or not.

I'm ok with this landing for now in WebKit, but I agree that it might want to
live in ANGLE.

I'll mark it as r+ and Ken can decide.