I've noticed that we are receiving UpdateBackingStoreState messages in the web process even when size and scale factor didn't change. That's quite unfortunate because we do a lot of work unnecessarily and we tell the threaded compositor that the size changed. This is not only a problem because it's not rue, but also because changing the size is a sync operation in the threade compositor, so we block the compositing thread for nothing. This is happening because the WebPageProxy notifies the drawing area that the backing store is discardable when the page is not visible, and that always produces a new backing store state. In accelerating compositing mode we don't even have a backing store to discard, so we should check we have something to discard and also make sure we only generate a new backing store state if we really discarded the backing store.
Created attachment 299237 [details] Patch
Well, perhaps I was too fast. Are we sure that the call to backingStoreStateDidChange(DoNotRespondImmediately); does not have side effects for other platforms?. It might be the case that they don't perform heavy operations but have to do somethin.
(In reply to comment #2) > Well, perhaps I was too fast. Are we sure that the call to > backingStoreStateDidChange(DoNotRespondImmediately); does not have side > effects for other platforms?. It might be the case that they don't perform > heavy operations but have to do somethin. I'm sure, because DrawingAreaProxyImpl is only used by GTK+ port :-)
Committed r210920: <http://trac.webkit.org/changeset/210920>