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

fpCefSharp does not support High DPI configurations #5

Closed
cwollenhaupt opened this issue Aug 31, 2021 · 1 comment · Fixed by #7
Closed

fpCefSharp does not support High DPI configurations #5

cwollenhaupt opened this issue Aug 31, 2021 · 1 comment · Fixed by #7
Assignees
Labels
bug Something isn't working

Comments

@cwollenhaupt
Copy link
Owner

Steps to reproduce
Change the DPI scaling factor to something larger than 100% (Desktop > Right Click > Display Settings > Scale and Layout)
Run demo_get.prg

Notice how the text boxes display properly.

Click into the first text box

Observed
The entire form is redrawn larger and slightly to the right/bottom.

image

This double drawing happens always if the DPI scaling factor is different from 100%.

@cwollenhaupt
Copy link
Owner Author

VFP9.EXE is not DPI aware. As such its being run in a DPI sandbox where the screen resolution appears to be lower than it actually is. When the scale factor is 200% (or 192 DPI) then a screen screen resolution of 3200x1600 is reported to VFP as 1600x800. Any output is then scaled by Windows automatically. This includes any Window frame, menu bars, and everything within the boundary of the window.

If you show the DPI Awareness column in Task Manager, then VFP9.EXE is clearly shown as "unaware".

CEF (and therefore CefSharp) relies on an out-of-process render engine which is hosted by CefSharp.BrowserSubProcess.EXE. This EXE has a manifest stating it's High DPI aware on a per monitor basis. As such Windows isn't sandboxing the EXE and reporting the actual screen resolution. The browser sub process therefore generates images scaled acording to the actual resolution.

This image is then passed to the VFP9.EXE application where Windows assumes it is based on 96 DPI/100% scale factor setting. Therefore Windows scales the image up accordingly when the CefSharp WinForm control updates the browser window when showing the caret (textbox cursor).

I performed two tests to verify that it's actually the mismatch between the BrowserSubProcess and VFP9:

Using the SetProcessDPIAware API function I changed the existing process to be DPI aware.

DECLARE long IsProcessDPIAware IN user32.dll
? isProcessDPIAware()
Declare long SetProcessDPIAware in win32api
? SetProcessDPIAware()
? isProcessDPIAware()

VFP was promptly resized by Windows to match the new unscaled size. Now demo_get.prg and the Google home page behaved as expected. This will only work if the application written in FoxPro can be made DPI Aware which isn't always possible due to some elements that are handled by VFP such as window borders and menus.

Next I did the opposite. I edited the manifest in the BrowserSubProcess and changed the value from true/PM to false. This also fixed the problem. CefSharp would render images that match the sandboxed size and Windows would automatically scale the result like everything else in the application resulting in a blurry view (which is expected for DPI unaware applications).

It is not clear why the initial rendering process is happening at the correct dimensions.

The proposed solution is to take the CefSharp.BrowserSubProcess.EXE from each release and copy it into CefSharp.BrowserSubProcess.DPIUnaware.EXE.

Modify the manifest file (some automated solution would be preferred)

In fpCefSharp call IsProcessDPIAware to determine which sub process executable is required. We then set BrowserSubprocessPath accordingly during the CefSharp initialization phase.

See also
https://github.com/cefsharp/CefSharp/wiki/General-Usage#high-dpi-additional-info
cefsharp/CefSharp#2927

@cwollenhaupt cwollenhaupt self-assigned this Aug 31, 2021
@cwollenhaupt cwollenhaupt added the bug Something isn't working label Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant