WebView does not display correctly after changing the Windows 10 scaling value > 100%

tuarua / WebViewANE

WebView Adobe Air Native Extension for macOS 10.10+, Windows Desktop, iOS 9.0+ and Android 19+. This ANE provides access to a more modern webview from AIR.

Apache License 2.0

183 stars 53 forks source link

WebView does not display correctly after changing the Windows 10 scaling value > 100% #263

Closed lgignoud closed 3 years ago

lgignoud commented 4 years ago

Have you read the Wiki carefully? Yes
What version of the product are you using? 2.12
On what operating system? Win 10
If Windows is the AIR app 32bit or 64bit? 64bit
Which IDE are you using? IntelliJ
Which version of AIR are you using? 32
What steps will reproduce the problem? On Windows 10, the option in Settings > System > Display > Scale and Layout causes some display issues when not set to 100%. You have to start the application after changing the value to see the problem. The WebView seems to translate to the right and bottom, and the text on a Flex application is blurry as soon as a WebView is opened. Is there a way to keep the WebView in its original position, regardless of the Windows scaling value ?

With 100%: 50%

With 125%: 125%

tuarua commented 4 years ago

It is not clear from your screen grabs above the problem you are mentioning. The examples are scaling correctly for me and are set-up for HiDPI support.

Please provide the exact code you are using (including the app-xml)

lgignoud commented 3 years ago

Hi Tuara, I finally find some time to dig into this issue. It seems related to the "DPI Awareness" of the application. You can see this in the task manager, with those instructions: https://winaero.com/see-dpi-awareness-task-manager-windows-10/

Steps to reproduce: If I launch the AIR app WITHOUT creating the webview at the beginning, and with a scale factor != 100%: The DPI Awareness of the app is "unavailable". As soon as the WebView is created, the whole AIR app DPI Awarness becomes "system" and the webview Cef subprocesses are "Per monitor". This cause some unexpected visual results.

The only workaround I found is to manually change the DPI settings of the app as explained here: https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update

But it's an extra step for the user, and one must do it again when upgrading the app.

Hope this help...

Amazing ANE by the way !

tuarua commented 3 years ago

Latest version 2.13.0 now uses a different Windows GetScaleFactor method which should be more reliable You will also need to upgrade to FreSharp 2.5.0

tuarua commented 3 years ago

Closing assumed fixed