[WebGL][EFL][Qt] Transparent canvas composited non-transparent.

[Viatcheslav Ostapenko]

Created attachment 179977 [details]
Picture of non-transparent composited canvas

Picture attached.

[Dongseong Hwang]

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.

[Dongseong Hwang]

I am wrong.
http://www.khronos.org/registry/webgl/specs/latest/#2.2

WebGL require clearing a drawing buffer after compositing. It's interesting.

[Viatcheslav Ostapenko]

Created attachment 180457 [details]
Patch

[Dongseong Hwang]

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

[Dongseong Hwang]

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

[Dongseong Hwang]

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 :)

[Dongseong Hwang]

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.

[Dongseong Hwang]

You already filed Bug 105326. Sorry for bothering sound.

[Dongseong Hwang]

Created attachment 180460 [details]
Patch

[Dongseong Hwang]

(In reply to comment #9)
> Created an attachment (id=180460) [details]
> Patch

Oops, I'm sorry for mistake.. I should post Bug 105326.

[Kenneth Rohde Christiansen]

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"

[Viatcheslav Ostapenko]

Created attachment 180526 [details]
Patch

[Kalyan]

(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.

[Kalyan]

(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.

[WebKit Review Bot]

Comment on attachment 180526 [details]
Patch

Clearing flags on attachment: 180526

Committed r138390: <http://trac.webkit.org/changeset/138390>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Viatcheslav Ostapenko]

(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.