TextureMapperGL stencil bug

• Component: New Bugs
• Status: RESOLVED INVALID

Hi,

Going through the TextureMapperGL implementation, I see that BeginClip advances the bit plane to the next 

clipStack().setStencilIndex(stencilIndex * 2);

However, EndClip does not revert it back before calling clipStack().applyIfNeeded(m_context3D.get());

The applyIfNeeded disables stencil test only if stencilIndex is 1.

if (clipState.stencilIndex == 1)
        context->disable(GraphicsContext3D::STENCIL_TEST);
    else
        context->enable(GraphicsContext3D::STENCIL_TEST); 

There is no place in the code that is attempting to reverse the impact of BeginClip. Isn’t a right bit shift required in the EndClip call before the applyIfNeeded call? Otherwise, I don’t see how EndClip will disable stenciling test ever. The problem is probably more obvious if you have nested clipping. 

You can also see the problem on classing falling leaves demo. The leaves are visible outside the center container.You'll first need to disable the scissor based clipping otherwise the stencil path would be optimized and never hit. 

Previous related changes - http://trac.webkit.org/changeset/108696 

--Arpit

I don't have GTK port running but looking closer, I think .pop will do the trick of lowering the bit plane.

I'll continue to investigate on my implementation and let you know the result.

[Byungseon(Sun) Shin]

Created attachment 235865 [details]
GTK Screen shot of Falling Leaves

FYI, I have tested GTK build based on latest upstream master branch and couldn't found any issues.

After further investigation, the bug report was a mistake on my end. My apologies.

--Arpit