Title: [281186] trunk/Source/WebKit
- Revision
- 281186
- Author
- [email protected]
- Date
- 2021-08-18 06:42:48 -0700 (Wed, 18 Aug 2021)
Log Message
REGRESSION (iOS 15): DoubleDown Casino app won't load past launch page
https://bugs.webkit.org/show_bug.cgi?id=229200
rdar://81636256
Reviewed by Myles C. Maxfield.
The changes in https://webkit.org/b/228216 to fix rdar://80473805 introduced a mechanism to keep track of uses
of cached fonts and images in display list items in the web and GPU processes, via a `useCount` counter variable
that's incremented in the web process whenever the font or image is used in a display list item and decremented
in the GPU process whenever the item is processed.
However, the code to increment `useCount` in the web process currently only triggers at most once per rendering
update — this means that if there are multiple canvas drawing commands that use fonts in the same rendering
update, the web process' notion of `useCount` will fall out of sync with the GPU process' notion of `useCount`.
In most cases, this causes the cached font to remain for longer in the GPU process than necessary; however, in
this specific scenario, it's possible for the web process to tell the GPU process to release the cached font too
early, which causes the GPU process to prematurely purge the font from the cache, and subsequently wait for the
cached font to arrive (which will never arrive, since the web process has already released the font).
In other words, the timeline of events between the web and GPU processes looks like this (where `f` is a cached
web font, `A_f` is a drawing command that uses `f`, and `B_f` is another drawing command that uses `f`).
WEB GPU
==============================================================
1. Cache `f`
2. Append `A_f`
3. Cache `f`
4. Play back `A_f`
5. Append `B_f`
6. Release `f` (use count was 1 here)
7. Release `f` (use count dropped from 1 to 0)
8. Play back `B_f`
...and then display list playback stops due to `f` not being in
the cache.
To address this, we simply move the `useCount` increment in the web process out of the rendering update check.
The original intent of the fix for bug #228216 was to allow for `useCount` to increment as many times as needed
per rendering update, so this limitation was unintentional.
Unfortunately, I have not been able to come up with a layout test that reliably reproduces this scenario (yet).
* WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp:
(WebKit::RemoteResourceCacheProxy::recordFontUse):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (281185 => 281186)
--- trunk/Source/WebKit/ChangeLog 2021-08-18 13:30:04 UTC (rev 281185)
+++ trunk/Source/WebKit/ChangeLog 2021-08-18 13:42:48 UTC (rev 281186)
@@ -1,3 +1,50 @@
+2021-08-18 Wenson Hsieh <[email protected]>
+
+ REGRESSION (iOS 15): DoubleDown Casino app won't load past launch page
+ https://bugs.webkit.org/show_bug.cgi?id=229200
+ rdar://81636256
+
+ Reviewed by Myles C. Maxfield.
+
+ The changes in https://webkit.org/b/228216 to fix rdar://80473805 introduced a mechanism to keep track of uses
+ of cached fonts and images in display list items in the web and GPU processes, via a `useCount` counter variable
+ that's incremented in the web process whenever the font or image is used in a display list item and decremented
+ in the GPU process whenever the item is processed.
+
+ However, the code to increment `useCount` in the web process currently only triggers at most once per rendering
+ update — this means that if there are multiple canvas drawing commands that use fonts in the same rendering
+ update, the web process' notion of `useCount` will fall out of sync with the GPU process' notion of `useCount`.
+
+ In most cases, this causes the cached font to remain for longer in the GPU process than necessary; however, in
+ this specific scenario, it's possible for the web process to tell the GPU process to release the cached font too
+ early, which causes the GPU process to prematurely purge the font from the cache, and subsequently wait for the
+ cached font to arrive (which will never arrive, since the web process has already released the font).
+
+ In other words, the timeline of events between the web and GPU processes looks like this (where `f` is a cached
+ web font, `A_f` is a drawing command that uses `f`, and `B_f` is another drawing command that uses `f`).
+
+ WEB GPU
+ ==============================================================
+ 1. Cache `f`
+ 2. Append `A_f`
+ 3. Cache `f`
+ 4. Play back `A_f`
+ 5. Append `B_f`
+ 6. Release `f` (use count was 1 here)
+ 7. Release `f` (use count dropped from 1 to 0)
+ 8. Play back `B_f`
+ ...and then display list playback stops due to `f` not being in
+ the cache.
+
+ To address this, we simply move the `useCount` increment in the web process out of the rendering update check.
+ The original intent of the fix for bug #228216 was to allow for `useCount` to increment as many times as needed
+ per rendering update, so this limitation was unintentional.
+
+ Unfortunately, I have not been able to come up with a layout test that reliably reproduces this scenario (yet).
+
+ * WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp:
+ (WebKit::RemoteResourceCacheProxy::recordFontUse):
+
2021-08-17 Sihui Liu <[email protected]>
Fix crash in TestWebKitAPI.NetworkProcess.CrashWhenNotAssociatedWithDataStore
Modified: trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp (281185 => 281186)
--- trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp 2021-08-18 13:30:04 UTC (rev 281185)
+++ trunk/Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp 2021-08-18 13:42:48 UTC (rev 281186)
@@ -132,9 +132,9 @@
}
auto& currentState = result.iterator->value;
+ ++currentState.useCount;
if (currentState.lastRenderingUpdateVersionUsedWithin != m_remoteRenderingBackendProxy.renderingUpdateID()) {
currentState.lastRenderingUpdateVersionUsedWithin = m_remoteRenderingBackendProxy.renderingUpdateID();
- ++currentState.useCount;
++m_numberOfFontsUsedInCurrentRenderingUpdate;
}
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
