Changeset 269956 in webkit

Timestamp:

Nov 18, 2020 7:36:33 AM (3 years ago)

Author:

Chris Dumez

Message:

[GPUProcess] Main thread of the GPUProcess should have same priority as main thread of the WebContent
​https://bugs.webkit.org/show_bug.cgi?id=219057

Reviewed by Simon Fraser.

Main thread of the GPUProcess should have same priority as main thread of the WebContent since it
is doing rendering on its behalf.

For now, this means that on macOS, the main threads of the GPU and WebContent processes with both
get UserInteractive QoS. On iOS, they will both still get UserInitiated QoS until our RunningBoard
foreground process assertion get fixed to get the right priority (<rdar://problem/71499731>).

• GPUProcess/EntryPoint/Cocoa/XPCService/GPUService/Info-OSX.plist:

Use _ProcessType=App, similarly as what we do for the WebContent process. If we don't do
this, the process is an adaptive daemon and its QoS can never be higher than UserInitiated.
We need its priority to go to UserInteractive to match the WebContent process.

• GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):
Request UserInteractive QoS for the main thread of the GPUProcess, similarly to what we do
for the main thread of the WebContent process already in WebProcess::InitializeWebProcess().

Location:

trunk/Source/WebKit

Files:

• ChangeLog (modified) (1 diff)
• GPUProcess/EntryPoint/Cocoa/XPCService/GPUService/Info-OSX.plist (modified) (1 diff)
• GPUProcess/GPUProcess.cpp (modified) (1 diff)

trunk/Source/WebKit/ChangeLog

@@ +1 @@
+2020-11-18  Chris Dumez  <cdumez@apple.com>
+
+        [GPUProcess] Main thread of the GPUProcess should have same priority as main thread of the WebContent
+        https://bugs.webkit.org/show_bug.cgi?id=219057
+
+        Reviewed by Simon Fraser.
+
+        Main thread of the GPUProcess should have same priority as main thread of the WebContent since it
+        is doing rendering on its behalf.
+
+        For now, this means that on macOS, the main threads of the GPU and WebContent processes with both
+        get UserInteractive QoS. On iOS, they will both still get UserInitiated QoS until our RunningBoard
+        foreground process assertion get fixed to get the right priority (<rdar://problem/71499731>).
+
+        * GPUProcess/EntryPoint/Cocoa/XPCService/GPUService/Info-OSX.plist:
+        Use _ProcessType=App, similarly as what we do for the WebContent process. If we don't do
+        this, the process is an adaptive daemon and its QoS can never be higher than UserInitiated.
+        We need its priority to go to UserInteractive to match the WebContent process.
+
+        * GPUProcess/GPUProcess.cpp:
+        (WebKit::GPUProcess::initializeGPUProcess):
+        Request UserInteractive QoS for the main thread of the GPUProcess, similarly to what we do
+        for the main thread of the WebContent process already in WebProcess::InitializeWebProcess().
+
 2020-11-18  Sam Weinig  <weinig@apple.com>
 

trunk/Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUService/Info-OSX.plist

@@ -37 +37 @@
                 <key>RunLoopType</key>
                 <string>NSRunLoop</string>
+                <key>_ProcessType</key>
+                <string>App</string>
                 <key>_MultipleInstances</key>
                 <true/>

trunk/Source/WebKit/GPUProcess/GPUProcess.cpp

@@ -156 +156 @@
 #endif
 
+    // Match the QoS of the UIProcess since the GPU process is doing rendering on its behalf.
+    WTF::Thread::setCurrentThreadIsUserInteractive(0);
+
     WebCore::setPresentingApplicationPID(parameters.parentPID);
 }