Bug 58731

Summary: [Texmap] [Qt] Do not reset a texture if it comes from imageToTexture pool.
Product: WebKit Reporter: Young Han Lee <joybro201>
Component: PlatformAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: benjamin, eric, kbr, noam, skyul
Priority: P2 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 47070, 58903    
Bug Blocks:    
Attachments:
Description Flags
Patch eric: review-

Young Han Lee
Reported 2011-04-16 10:54:32 PDT
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.
Attachments
Patch (1.91 KB, patch)
2011-04-16 11:06 PDT, Young Han Lee 		eric: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Young Han Lee
Comment 1 2011-04-16 11:06:08 PDT
Created attachment 89926 [details] Patch
Noam Rosenthal
Comment 2 2011-04-16 11:15:04 PDT
LGTM
Benjamin Poulain
Comment 3 2011-04-17 05:16:28 PDT
Comment on attachment 89926 [details] Patch Any reason not to make a pixel test for the bug?
Young Han Lee
Comment 4 2011-04-17 19:36:27 PDT
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.
Noam Rosenthal
Comment 5 2011-04-17 20:42:58 PDT
(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.
Eric Seidel (no email)
Comment 6 2011-04-18 09:26:49 PDT
Comment on attachment 89926 [details] Patch How do we test this?
Kenneth Russell
Comment 7 2011-04-18 13:16:33 PDT
In Chromium glReadPixels is used in order to run pixel tests for the accelerated compositor.
Young Han Lee
Comment 8 2011-04-18 18:49:39 PDT
(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.
Kenneth Russell
Comment 9 2011-04-18 19:20:32 PDT
(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.
Young Han Lee
Comment 10 2011-04-19 09:08:04 PDT
(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.
Noam Rosenthal
Comment 11 2012-02-14 04:35:43 PST
Code has completely changed, this no longer applies.
Note You need to log in before you can comment on or make changes to this bug.