Bug 105325

It can be reproduced in WK1 Qt but I think efl and qt are fine. I think http://aleksandarrodic.com/p/jellyfish/ is wrong. The demo call glClear(GL_DEPTH_BUFFER_BIT) every frame instead of glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT), so result image is accumulated. I think chromium has a bug to clear color bit every frame regardless of web author's purpose.

I am wrong. http://www.khronos.org/registry/webgl/specs/latest/#2.2 WebGL require clearing a drawing buffer after compositing. It's interesting.

Created attachment 180457 [details] Patch

no, it is not good approach. I also made fix almost. please wait a moment

Created attachment 180458 [details] WIP : clear a drawing buffer after compositing.

Comment on attachment 180458 [details] WIP : clear a drawing buffer after compositing. I think our both patch are needed for separate reason. I don't understand your patch fully yet. I'll read :)

I'll file preserveDrawingBuffer bug in another bug. I posted not matching patch here. http://aleksandarrodic.com/p/jellyfish/ has two bugs. 1. transparent bug 2. preserve drawing buffer bug. You fixed #1, and I fixed #2. great.

You already filed Bug 105326. Sorry for bothering sound.

Created attachment 180460 [details] Patch

(In reply to comment #9) > Created an attachment (id=180460) [details] > Patch Oops, I'm sorry for mistake.. I should post Bug 105326.

Comment on attachment 180457 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=180457&action=review LGTM, but some minor issues > Source/WebCore/ChangeLog:3 > + [WebGL][EFL][Qt] Transparent canvas composited non-transparent. No dot in bugzilla titles > Source/WebCore/ChangeLog:10 > + even if window itself has alpha channel because 1st GLXFBConfig in a list > + is without transparency. I dont understand these two lines > Source/WebCore/platform/graphics/surfaces/glx/GraphicsSurfaceGLX.cpp:249 > + // If origin window has alpha then try to find config with alpha. > + GLXFBConfig& config = m_hasAlpha ? findFBConfigWithAlpha(configs, numberOfConfigs) : configs[0]; So what is the result if it fails? are we just out of luck? > Source/WebCore/platform/graphics/surfaces/glx/GraphicsSurfaceGLX.cpp:367 > + // Return 1st config as a fallback. > + return fbConfigs[0]; You should write here what that means, like "no alpha support"

Created attachment 180526 [details] Patch

(In reply to comment #11) > (From update of attachment 180457 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=180457&action=review > > > + GLXFBConfig& config = m_hasAlpha ? findFBConfigWithAlpha(configs, numberOfConfigs) : configs[0]; > > So what is the result if it fails? are we just out of luck? > If this was related to finding alpha config: we should be fine if both the pixmap/window (shared handle) and one created here are created with a visual corresponding to the same config(alpha or no-alpha). Any config mis-match would highlight issues in the config selection logic of either the shared pixmap or at this end. This would generate a BadMisMatch error.

(In reply to comment #11) > (From update of attachment 180457 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=180457&action=review > > > > Source/WebCore/ChangeLog:10 > > + even if window itself has alpha channel because 1st GLXFBConfig in a list > > + is without transparency. > > I dont understand these two lines > This highlights the fact that we are using mismatching configs. Currently the shared window/pixmap always uses a visual with Alpha. We should be able to configure this depending on the GraphicsContext3D attributes in future. Probably this should be highlighted here.

Comment on attachment 180526 [details] Patch Clearing flags on attachment: 180526 Committed r138390: <http://trac.webkit.org/changeset/138390>

All reviewed patches have been landed. Closing bug.

(In reply to comment #14) > (In reply to comment #11) > > (From update of attachment 180457 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=180457&action=review > > > > > > > > Source/WebCore/ChangeLog:10 > > > + even if window itself has alpha channel because 1st GLXFBConfig in a list > > > + is without transparency. > > > > I dont understand these two lines > > > > This highlights the fact that we are using mismatching configs. Currently the shared window/pixmap always uses a visual with Alpha. We should be able to configure this depending on the GraphicsContext3D attributes in future. Probably this should be highlighted here. Why here? Create a bug about it.