• bdakin@apple.com's avatar
    Need a LayoutMilestone to fire when we have done our first paint after suppressing · 72d30d8b
    bdakin@apple.com authored
    incremental layout
    -and corresponding-
    Reviewed by Simon Fraser.
    To meet the needs of all of our clients, we really need two milestones. One 
    indicating that a layout has happened after setVisualUpdatesAllowed(true), and 
    another indicating that painting has happened.
    If layout is needed when setVisualUpdatesAllowed(true) is called, we need to 
    update it so that we can guarantee the first paint is really happening at this 
    time. Also fire the DidFirstLayoutAfterSuppressedIncrementalRendering milestone, 
    and call add DidFirstPaintAfterSuppressedIncrementalRendering to the FrameView's 
    pending paint milestones. 
    up the painting milestone.
    * dom/Document.cpp:
    FrameView now stores m_milestonesPendingPaint. We'll send and clear them once we 
    have painted.
    * page/FrameView.cpp:
    * page/FrameView.h:
    Two new milestones.
    * page/LayoutMilestones.h:
    We don't need m_headerLayerAwaitingFirstFlush anymore since we can use FrameView's 
    pending paint milestones instead.
    * rendering/RenderLayerCompositor.cpp:
    * rendering/RenderLayerCompositor.h:
    Two new millstones.
    * Shared/API/c/WKPageLoadTypes.h:
    * Shared/API/c/WKSharedAPICast.h:
    This null-check is necessary now since this code ends up running at 
    WebFrame::init() time while we're setting up the Document. 
    setVisualUpdatesAllowed(true) has always been called as a part of that process, 
    and now the updateLayout(), ends up calling this code too, but we don't actually 
    have a mainFrame yet since it's still being created.
    * WebProcess/WebCoreSupport/WebChromeClient.cpp:
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149317 268f45cc-cd09-0410-ab3c-d52691b4dbfc