[Webkit-unassigned] [Bug 117550] [CSS Shaders] Animations and transitions should use validated custom programs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=117550





--- Comment #12 from Ralph T <ralpht+bugs at gmail.com>  2013-06-19 07:35:54 PST ---
This change was rolled out because it caused an assert in StyleCustomFilterProgram.h StyleCustomFilterProgram::isLoaded called from RenderLayer::computeFilterOperations.


    virtual bool isLoaded() const
    {
        // Do not use the CachedResource:isLoaded method here, because it actually means !isLoading(),
        // so missing and canceled resources will have isLoaded set to true, even if they are not loaded yet.
        ASSERT(!m_vertexShader || m_vertexShader->isCachedShader());
        ASSERT(!m_fragmentShader || m_fragmentShader->isCachedShader());
        ASSERT(m_cachedVertexShader.get() || m_cachedFragmentShader.get());
        return (!m_cachedVertexShader.get() || m_isVertexShaderLoaded)
            && (!m_cachedFragmentShader.get() || m_isFragmentShaderLoaded);
    }

The third assert failed on keyframe animations where the custom filter existed only in a keyframe and had never been loaded before -- m_cachedVertexShader and m_cachedFragmentShader were both null.

If I do something to cause StyleCustomFilterProgram::willHaveClients to be called then the layout tests work without assertions.

I'm not sure what the right approach is here. Some questions:

1. Are there any other keyframe animatable resources which are loaded?

2. Does the RenderLayer want to become the loader client for all custom shaders in keyframes for the duration of the keyframe animation?

3. Does anything break like this if the server is slow to serve up fragment and vertex shaders? (i.e.: in the unanimated case, RenderLayer::computeFilterOperations is called with custom shaders in a state that the assertions above fail). I can test this one later today.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.