Title: [210920] trunk/Source/WebKit2
- Revision
- 210920
- Author
- [email protected]
- Date
- 2017-01-19 00:59:42 -0800 (Thu, 19 Jan 2017)
Log Message
[GTK] Do not update the backing store state unnecessarily when page visibility changes
https://bugs.webkit.org/show_bug.cgi?id=167195
Reviewed by Sergio Villar Senin.
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 true, but also because
changing the size is a sync operation in the threaded 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.
* UIProcess/DrawingAreaProxyImpl.cpp:
(WebKit::DrawingAreaProxyImpl::discardBackingStoreSoon):
(WebKit::DrawingAreaProxyImpl::discardBackingStore):
Modified Paths
Diff
Modified: trunk/Source/WebKit2/ChangeLog (210919 => 210920)
--- trunk/Source/WebKit2/ChangeLog 2017-01-19 08:40:05 UTC (rev 210919)
+++ trunk/Source/WebKit2/ChangeLog 2017-01-19 08:59:42 UTC (rev 210920)
@@ -1,3 +1,23 @@
+2017-01-19 Carlos Garcia Campos <[email protected]>
+
+ [GTK] Do not update the backing store state unnecessarily when page visibility changes
+ https://bugs.webkit.org/show_bug.cgi?id=167195
+
+ Reviewed by Sergio Villar Senin.
+
+ 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 true, but also because
+ changing the size is a sync operation in the threaded 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.
+
+ * UIProcess/DrawingAreaProxyImpl.cpp:
+ (WebKit::DrawingAreaProxyImpl::discardBackingStoreSoon):
+ (WebKit::DrawingAreaProxyImpl::discardBackingStore):
+
2017-01-18 Said Abou-Hallawa <[email protected]>
[iOS][WK2] Remove the WebView private configuration contentUpdateFrequency
Modified: trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp (210919 => 210920)
--- trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp 2017-01-19 08:40:05 UTC (rev 210919)
+++ trunk/Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp 2017-01-19 08:59:42 UTC (rev 210920)
@@ -175,7 +175,7 @@
void DrawingAreaProxyImpl::discardBackingStoreSoon()
{
- if (!m_isBackingStoreDiscardable || m_discardBackingStoreTimer.isActive())
+ if (!m_backingStore || !m_isBackingStoreDiscardable || m_discardBackingStoreTimer.isActive())
return;
// We'll wait this many seconds after the last paint before throwing away our backing store to save memory.
@@ -187,6 +187,8 @@
void DrawingAreaProxyImpl::discardBackingStore()
{
+ if (!m_backingStore)
+ return;
m_backingStore = nullptr;
backingStoreStateDidChange(DoNotRespondImmediately);
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
