Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Force high-performance GPU for WebView2 #5072

Open
AshleyScirra opened this issue Jan 30, 2025 · 0 comments
Open

[Feature]: Force high-performance GPU for WebView2 #5072

AshleyScirra opened this issue Jan 30, 2025 · 0 comments
Labels
feature request feature request

Comments

@AshleyScirra
Copy link

AshleyScirra commented Jan 30, 2025

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!

@AshleyScirra AshleyScirra added the feature request feature request label Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request feature request
Projects
None yet
Development

No branches or pull requests

1 participant