[Webkit-unassigned] [Bug 96115] New: TextureMapper Textures created too late, creates flicker and lag.

[bugzilla-daemon at webkit.org]

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

           Summary: TextureMapper Textures created too late, creates
                    flicker and lag.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: florian.haenel at heeen.de


We use Qt, but I think it should be reproducible in other ports. 

Usecase:
1) A browser window with accelerated compositing pops up, after an initial layout accelerated compositing is detected and layers with texture backing stores created.
   The user can interact with the page seamlessly.

2) The user pushes the browser view in the background, for which we disable accelerated compositing for lack of a GL context in this scenario on our platform.
   We can render using software rasterization in this mode fine.

3) The browser gets pulled back from background and regains a GL context. We re-enable accelerated compositing, but no root compositing layer is created at this point.
   The user tries to interact with css-transformed content - style change triggers actual layer creation and texture uploads.
   Texture uploads take a few milliseconds, during which empty layers get shown! So we get a visual flicker.
   After Layer creation, everytinh works as usual.

Analysis:
When resuming AC, we trigger a trigger a dummy style change which is supposed to cause a cascade of style recalculations leading to the creation and uploading of the layers.

void Settings::setAcceleratedCompositingEnabled(bool enabled)
{
    if (m_acceleratedCompositingEnabled == enabled)
        return;

    m_acceleratedCompositingEnabled = enabled;
    m_page->setNeedsRecalcStyleInAllFrames();
}

however, for some reason, a re-layout is pending which causes the compositing changes to be ignored:

void Document::recalcStyle(StyleChange change)
(...)
        bool layoutPending = view()->layoutPending() || renderer()->needsLayout();
        // If we didn't update compositing layers because of layout(), we need to do so here.
        if (!layoutPending) {
            view()->updateCompositingLayersAfterStyleChange();
        }
Then, in the layout phase, the compositing changes also get ignored, because transform does not set the re-evaluate compositing flag:

bool RenderLayerCompositor::requiresCompositingForTransform(RenderObject* renderer) const
{
    if (!(m_compositingTriggers & ChromeClient::ThreeDTransformTrigger))
        return false;

    // THIS IS NOT HERE ORIGINALLY, ADDED BY ME
    m_reevaluateCompositingAfterLayout = true;

    RenderStyle* style = renderer->style();
    // Note that we ask the renderer if it has a transform, because the style may have transforms,
    // but the renderer may be an inline that doesn't suppport them.
    return renderer->hasTransform() && (style->transform().has3DOperation() || style->transformStyle3D() == TransformStyle3DPreserve3D || style->hasPerspective());
}

however, Position-fixed, among plugin and frame, does trigger this flag:
bool RenderLayerCompositor::requiresCompositingForPosition(RenderObject* renderer, const RenderLayer* layer) const
{ (...)
// If the renderer is not hooked up yet then we have to wait until it is.
    if (!container) {
        sDebug()<<"reevaluate compositing because no container";
        m_reevaluateCompositingAfterLayout = true;
        return false;
    }


So I am trying to understand what the right thing to do is here. I added that reevaluation flag and it seems to work for my usecase.
But it feels like the other cases in the RenderLayerCompositor::requiresCompositionFor* family would then be left out and have the same issue, and checking for that flag probably has a reason.
So is there a more generic solution for this? I'd like to hear input from someone more familiar in this area.

Qt4.8/WK1

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