You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some devices like gaming laptops have a dual-GPU architecture. They have a weak, low-power integrated GPU for saving battery, and a much faster high-power discrete GPU for gaming.
Currently the Chromium browser engine defaults to using the low-power integrated GPU. When requesting the discrete GPU for WebGL or WebGPU content via explicitly requesting "high-performance", it still uses the low-power integrated GPU, because Chromium does not yet support compositing content from different GPUs on Windows.
For content with demanding graphical requirements like games built with web technologies, the integrated GPU default is unsuitable. It results in poor performance on dual-GPU systems, and often results in complaints or poor reviews from players. Currently this is very difficult to work around because WebView2 uses a separate process: existing solutions like using system GPU settings to change the default GPU, or specifying NvOptimusEnablement in the main executable, are ineffective as they modify only the main application process and not the WebView GPU process.
Therefore to make use of the discrete GPU, we need a way to tell WebView2 to default to the discrete GPU rather than the integrated GPU.
The scenario/use case where you would use this feature
With our browser-based game development tool Construct, we are in the process of migrating from NW.js to WebView2 for Windows content, and this has come up as an important issue to resolve. This affects all Windows content published by Construct, which includes Steam titles like Moonstone Island (~3000 reviews, "Very positive"), Astral Ascent (~4000 reviews, "Very positive") and Pepper Grinder (listed in Ars Technica's top 20 video games of 2024). We want to make sure all Construct content published to Windows defaults to the discrete GPU, as most other games do, but currently there does not appear to be a way to do this.
This problem could be worked around with NW.js as with the --in-process-gpu flag the main application process does the GPU work so other workarounds apply. However with WebView2 even when that flag is applied, the application process and WebView2 processes remain separate and so the other workarounds don't work. Therefore this is a problem when migrating from other web frameworks like NW.js to WebView2.
How important is this request to you?
Impactful. My app's user experience would be significantly compromised without it.
Suggested implementation
A straightforward solution for the app to specify this would be to provide an option when creating WebView2 to force the high-power GPU, something along the lines of:
This would then force the GPU process to choose the high-power GPU for all rendering, and so also use that GPU for WebGL and WebGPU content.
What does your app do? Is there a pending deadline for this request?
With Construct we are currently aiming to complete our migration from NW.js to WebView2 by the middle of the year (June/July), so it would be great to have a solution by then.
Alternatively if anyone on the WebView2 team can figure out the right command-line arguments to pass to achieve this, that could do as an interim measure - perhaps something involving --gpu-preferences? However as command-line arguments are subject to change, a properly supported API would certainly be preferable.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered:
Describe the feature/enhancement you need
Some devices like gaming laptops have a dual-GPU architecture. They have a weak, low-power integrated GPU for saving battery, and a much faster high-power discrete GPU for gaming.
Currently the Chromium browser engine defaults to using the low-power integrated GPU. When requesting the discrete GPU for WebGL or WebGPU content via explicitly requesting "high-performance", it still uses the low-power integrated GPU, because Chromium does not yet support compositing content from different GPUs on Windows.
For content with demanding graphical requirements like games built with web technologies, the integrated GPU default is unsuitable. It results in poor performance on dual-GPU systems, and often results in complaints or poor reviews from players. Currently this is very difficult to work around because WebView2 uses a separate process: existing solutions like using system GPU settings to change the default GPU, or specifying
NvOptimusEnablement
in the main executable, are ineffective as they modify only the main application process and not the WebView GPU process.Therefore to make use of the discrete GPU, we need a way to tell WebView2 to default to the discrete GPU rather than the integrated GPU.
The scenario/use case where you would use this feature
With our browser-based game development tool Construct, we are in the process of migrating from NW.js to WebView2 for Windows content, and this has come up as an important issue to resolve. This affects all Windows content published by Construct, which includes Steam titles like Moonstone Island (~3000 reviews, "Very positive"), Astral Ascent (~4000 reviews, "Very positive") and Pepper Grinder (listed in Ars Technica's top 20 video games of 2024). We want to make sure all Construct content published to Windows defaults to the discrete GPU, as most other games do, but currently there does not appear to be a way to do this.
This problem could be worked around with NW.js as with the --in-process-gpu flag the main application process does the GPU work so other workarounds apply. However with WebView2 even when that flag is applied, the application process and WebView2 processes remain separate and so the other workarounds don't work. Therefore this is a problem when migrating from other web frameworks like NW.js to WebView2.
How important is this request to you?
Impactful. My app's user experience would be significantly compromised without it.
Suggested implementation
A straightforward solution for the app to specify this would be to provide an option when creating WebView2 to force the high-power GPU, something along the lines of:
options->put_ForceGPUPreference(COREWEBVIEW2_GPU_PREFERENCE_HIGH_POWER);
This would then force the GPU process to choose the high-power GPU for all rendering, and so also use that GPU for WebGL and WebGPU content.
What does your app do? Is there a pending deadline for this request?
With Construct we are currently aiming to complete our migration from NW.js to WebView2 by the middle of the year (June/July), so it would be great to have a solution by then.
Alternatively if anyone on the WebView2 team can figure out the right command-line arguments to pass to achieve this, that could do as an interim measure - perhaps something involving
--gpu-preferences
? However as command-line arguments are subject to change, a properly supported API would certainly be preferable.Thanks for your consideration!
The text was updated successfully, but these errors were encountered: