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
We are looking into an issue in one of our apps which mixes a native GUI and an embedded WebView2. This app is a plugin (an audio plugin that runs in third-party audio host apps) and can thus end up running in a variety of DPI-awareness contexts, depending on the settings and implementation of the host app.
We are running into an issue when the System Text Scaling is not 100%, and I think the issue stems from this WebView2 behavior noted by @champnic --
I believe we tie the text setting with DPI scaling for both the browser and WebView2
For both of these images, the DPI is held constant and the "Make Everything Bigger" setting stayed at 100%. The "make text bigger" setting was the difference. The "native" (implemented with JUCE) part of the GUI is the toolbar at the top of the plugin GUI, with the "Default" text / "IN" / "A/B" / "..." button etc. The WebView2 is the GUI below it with the Manley VoxBox gui for the audio processor. (let me know if I should clarify any of that, I could mark up a screenshot if helpful!)
Text scale at 100%:
Text scale at 225%, notice the web contents are scaled by Text Scale but the native parts of the GUI aren't:
So the native part of the GUI is DPI-aware and works correctly when resolution, DPI, and "make everything bigger" change, however it does not change when the TextScaleFactor is changed, as the Win32 APIs for DPI don't seem to take this into account. (This is how the GUI framework we use, JUCE, implements this, using the Win32 DPI APIs) This seems correct to me, since we wouldn't want to scale the entire GUI based on the text scale factor, right?
So I'm not sure the current WebView2 behavior of scaling everything according to TextScaleFactor is correct, since it ends up scaling everything, rather than just text. Is there some way we can opt-out of this scaling in the web view from our web view handling code, but still remain DPI aware? If not, any other ideas for making native GUIs play nice with their embedded WebView2 in this regard?
Let me know if I can clarify any thing or offer more info.
The text was updated successfully, but these errors were encountered:
Hey @jcampbellcodes - thanks for the question. Unfortunately it doesn't seem that there is a flag or other way to change the behavior of how we respond to the text scale factor. You are right that technically speaking the intent of the text factor setting is to only scale the text (with some UI reflow logic), but that would break web standards and lots of websites, so instead we (chromium + Edge + WebView2) landed on the current design of scaling everything.
I think you may be able to set the CoreWebView2Controller.ShouldDetectMonitorScaleChanges to true and then set the CoreWebView2Controller.RasterizationScale to the desired scaling value. Though I think we currently have a bug where if the RasterizationScale doesn't match the expected value of monitor scale * text scale that the web content appears slightly blurry. Or you could try using the ZoomFactor property to counteract the apparent zooming due to the text scale factor.
Or the other option would be to have the native part of the UI behave in the same way and increase scaling. Sounds like the native GUI is not responding at all to the TextScaleFactor.
None of these are ideal, but let me know if any of them suffice for your scenario or if you have other questions. Thanks!
Hey there!
We are looking into an issue in one of our apps which mixes a native GUI and an embedded WebView2. This app is a plugin (an audio plugin that runs in third-party audio host apps) and can thus end up running in a variety of DPI-awareness contexts, depending on the settings and implementation of the host app.
We are running into an issue when the System Text Scaling is not 100%, and I think the issue stems from this WebView2 behavior noted by @champnic --
I believe we tie the text setting with DPI scaling for both the browser and WebView2
Originally posted by @champnic in #1662 (comment)
For both of these images, the DPI is held constant and the "Make Everything Bigger" setting stayed at 100%. The "make text bigger" setting was the difference. The "native" (implemented with JUCE) part of the GUI is the toolbar at the top of the plugin GUI, with the "Default" text / "IN" / "A/B" / "..." button etc. The WebView2 is the GUI below it with the Manley VoxBox gui for the audio processor. (let me know if I should clarify any of that, I could mark up a screenshot if helpful!)
Text scale at 100%:
Text scale at 225%, notice the web contents are scaled by Text Scale but the native parts of the GUI aren't:
So the native part of the GUI is DPI-aware and works correctly when resolution, DPI, and "make everything bigger" change, however it does not change when the TextScaleFactor is changed, as the Win32 APIs for DPI don't seem to take this into account. (This is how the GUI framework we use, JUCE, implements this, using the Win32 DPI APIs) This seems correct to me, since we wouldn't want to scale the entire GUI based on the text scale factor, right?
So I'm not sure the current WebView2 behavior of scaling everything according to TextScaleFactor is correct, since it ends up scaling everything, rather than just text. Is there some way we can opt-out of this scaling in the web view from our web view handling code, but still remain DPI aware? If not, any other ideas for making native GUIs play nice with their embedded WebView2 in this regard?
Let me know if I can clarify any thing or offer more info.
The text was updated successfully, but these errors were encountered: