Compositing layer sync should cause deferred repaints to be fired immediately

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Tim Horton]

When we sync compositing layer state, we need to paint immediately, no matter what; otherwise we might see a visible flash before painting occurs.

[Radar WebKit Bug Importer]

<rdar://problem/11792028>

[Tim Horton]

Created attachment 150475 [details]
patch

[Simon Fraser (smfr)]

Comment on attachment 150475 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150475&action=review

> Source/WebCore/page/FrameView.cpp:752
>      root->compositor()->flushPendingLayerChanges(rootFrameForSync == m_frame);
>  
> +    // If we sync compositing layers and allow the repaint to be deferred, there is time for a
> +    // visible flash to occur. Instead, stop the deferred repaint timer and repaint immediately.
> +    stopDelayingDeferredRepaints();

I think we should swap these around.

If deferred repaints at some point affects compositing layers (it does not yet), then we'd want those repaints to get flushed.

[Antti Koivisto]

Comment on attachment 150475 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150475&action=review

> Source/WebCore/page/FrameView.cpp:1948
> +    if (!m_deferredRepaintTimer.isActive())
> +        return;
> +
>      m_deferredRepaintTimer.stop();

This does not make any sense.

[Antti Koivisto]

Comment on attachment 150475 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150475&action=review

>> Source/WebCore/page/FrameView.cpp:1948
>>      m_deferredRepaintTimer.stop();
> 
> This does not make any sense.

Actually it does, I misread!

[Tim Horton]

http://trac.webkit.org/changeset/121708