Bug 130984 – Synchronize Web process remote layer tree commits with CoreAnimation commits in the UI process

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Tim Horton]

Created attachment 228193 [details]
patch

There's no reason for the Web process to paint faster than the UI process
can apply to and commit the CoreAnimation layer tree.

Also, once we get proper double-buffering and purgeable back buffers, we
will need the ability to make some assumptions about in-use surfaces.

Unfortunately, we can't actually tell when the render server commits, 
as this is an asynchronous operation in a process we don't control, so
for now, this is only an approximation.

This also means that the assumptions we would like to make won't be
strong guarantees yet.

[WebKit Commit Bot]

Attachment 228193 [details] did not pass style-queue:


ERROR: Source/WebKit2/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 7 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Simon Fraser (smfr)]

Comment on attachment 228193 [details]
patch

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

> Source/WebKit2/UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:293
> +    m_layerCommitObserver = adoptCF(CFRunLoopObserverCreate(0, kCFRunLoopBeforeWaiting | kCFRunLoopExit, true, DidCommitLayersRunLoopOrder, coreAnimationDidCommitLayersCallback, &context));

Do we need to explicitly invalidate this guy in the destructor?

> Source/WebKit2/WebProcess/WebPage/DrawingArea.h:144
> +    virtual void didSwapBackingStore() { }

Not super keen on this name.

> Source/WebKit2/WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.h:116
> +    bool m_hasFlushDeferredWhileWaitingForBackingStoreSwap;

hadFlushDeferredWhileWaitingForBackingStoreSwap?

[Tim Horton]

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