imageToTexture is a pool of textures to share it between BitmapTextureGLs. The textures in the pool are already initialized and filled with image data, so they doesn't have to be initialized again when it comes from the pool. The current implementation always reset the texture whether it is found in the pool or new. This causes a problem that openGL draws a texture, which has garbage data, to screen.
Created attachment 89926 [details] Patch
LGTM
Comment on attachment 89926 [details] Patch Any reason not to make a pixel test for the bug?
I'm not sure it's possible to test animation features like this using a pixel test. If so, please let me know any hint.
(In reply to comment #3) > (From update of attachment 89926 [details]) > Any reason not to make a pixel test for the bug? We still don't have a way to pixel-test the opengl backend. If we had, the tests under LayoutTests/compositing should be sufficient for these optimizations.
Comment on attachment 89926 [details] Patch How do we test this?
In Chromium glReadPixels is used in order to run pixel tests for the accelerated compositor.
(In reply to comment #7) > In Chromium glReadPixels is used in order to run pixel tests for the accelerated compositor. Could you refer me to the Chrominum's pixel test cases or DRT code for those tests which is using glReadPixels? I failed to find how Chromium does to test accelerated compositor in WebKit source.
(In reply to comment #8) > (In reply to comment #7) > > In Chromium glReadPixels is used in order to run pixel tests for the accelerated compositor. > > Could you refer me to the Chrominum's pixel test cases or DRT code for those tests which is using glReadPixels? > I failed to find how Chromium does to test accelerated compositor in WebKit source. Chromium's test expectations for tests involving the compositor are checked in under LayoutTests/platform/chromium-gpu/compositing/. There are several places in Chromium's code where the behavior is switched between the full browser and DRT. One example is using the real OpenGL on the system vs. the Mesa software renderer. However, the key place where the readback is done for DRT is in WebViewImpl::paint, Source/WebKit/chromium/src/WebViewImpl.cpp. When running in DRT, the passed-in WebCanvas is non-NULL, and the readback is done.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > In Chromium glReadPixels is used in order to run pixel tests for the accelerated compositor. > > > > Could you refer me to the Chrominum's pixel test cases or DRT code for those tests which is using glReadPixels? > > I failed to find how Chromium does to test accelerated compositor in WebKit source. > > Chromium's test expectations for tests involving the compositor are checked in under LayoutTests/platform/chromium-gpu/compositing/. > > There are several places in Chromium's code where the behavior is switched between the full browser and DRT. One example is using the real OpenGL on the system vs. the Mesa software renderer. However, the key place where the readback is done for DRT is in WebViewImpl::paint, Source/WebKit/chromium/src/WebViewImpl.cpp. When running in DRT, the passed-in WebCanvas is non-NULL, and the readback is done. Thanks for the detailed reply. It seems that Qt's WebKit and DRT also have to be modified in the same way for a pixel-test. I will try to patch this in the near future.
Code has completely changed, this no longer applies.