File Viewer window displays incorrectly on high DPI displays

[jblang]

On high DPI displays with greater than 100% display scaling enabled, the File Viewer dialog doesn't display properly. When it initially comes up, the window is too narrow, causing buttons to draw on top of each other like this:

Resizing the window causes the button text to become garbled:

Moving the window so the corrupted portion goes off the screen and then back on causes the buttons to redraw correctly.

I am using CiderPress 4.1.0 on Windows 11 with a scaling factor of 150%. I suspect but have not confirmed that this would also happen on Windows 10 with display scaling enabled.

[fadden]

On Win10, I right-clicked on the background, selected "Display settings", scrolled down to "Scale and layout", and changed the value in the "Change the size of text, apps, and other items" pop-up. This caused Chrome to update its layout significantly, but had no effect on Ciderpress, whether it was running during the change or launched after.

I tried changing the "Make text bigger" setting in the Ease of Access setting. This affected the main Ciderpress window, but had no effect on the file viewer. In that same area of settings, the "Make everything bigger" pop-up made everything bigger with no distortion.

I haven't been able to reproduce the problem on Win10. Can you confirm the steps you're using to set the display scaling?

The file viewer does manage control repositioning itself, and appears to be the only window in CiderPress to do this sort of live scaling. It's possible the code is wrong but happened to work anyway until Win11. There's a comment in the code that says, "Use deferred reposn so that they don't end up drawing on top of each other and getting all weird"; from what I can tell, the point of that is to prevent visual artifacts from controls drawing on top of each other. Maybe that no longer works in Win11?

I figure there are two fixes needed: (1) ensure the dialog is initially large enough to show all the buttons in the current scaling; and (2) figure out a workaround for the blurry redraw.

[fadden]

Hmm... does resizing the file viewer window make things garbled if the display scale is at 100%, or does it only get weird when scaled up?

[jblang]

When scaling is set to 100%, the window is an appropriate width to begin with and will not allow you resize it so that it is too narrow to display all the buttons properly, so there is no chance for them to become garbled. Basically I think the problem is just that the code that determines the default and minimum window width is not taking scaling into account.

[jblang]

This is where I'm setting the scaling factor....

[jblang]

I have just confirmed the same thing happens on my Windows 10 laptop. You must restart CiderPress after changing the scale so that it natively scales rather than Windows just upscaling the window using interpolation. That may be what you are missing to reproduce it. Edit: sorry, just reread your first comment and I see that you did try restarting. I'm not sure why you can't reproduce it then.

[jblang]

Perhaps you just need to use this API to get the scaling factor and then multiply the default values by it here

[fadden]

That helped; I'm able to reproduce it in Win10. My problem was that I have multiple displays, and the control scaling behavior is determined by the configuration of the primary display. If a secondary display is different, the app snaps to the new size (via interpolation) when you drag it from one window to another, but you don't get a different control layout no matter how hard you try.

The API you identified seems to work:

void ViewFilesDialog::OnGetMinMaxInfo(MINMAXINFO* pMMI)
{
    // https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/dpi-related-apis-and-registry-settings?view=windows-11#primary-display-dpi-scale-factor
    // Get desktop dc
    HDC desktopDc = ::GetDC(NULL);
    // Get native resolution
    int horizontalDPI = GetDeviceCaps(desktopDc, LOGPIXELSX);
    int verticalDPI = GetDeviceCaps(desktopDc, LOGPIXELSY);

    float scaleFactor = horizontalDPI / 96.0f;
    LOGI("Native DPI: %dx%d, scaleFactor=%.3f", horizontalDPI, verticalDPI, scaleFactor);

    pMMI->ptMinTrackSize.x = (int)(664 * scaleFactor);
    pMMI->ptMinTrackSize.y = (int)(200 * scaleFactor);
}

Result:

C:\Src\ciderpress\app\ViewFilesDialog.cpp(165) : Native DPI: 120x120, scaleFactor=1.250
C:\Src\ciderpress\app\ViewFilesDialog.cpp(177) : Dialog: new size 812,469

Looks good. I'll upload a development release later today.

[fadden]

Update is available here: https://github.com/fadden/ciderpress/releases/tag/v4.1.1-d1

The initial and minimum window sizes are independent; both have been updated, so the window will start just wide enough to show 80 columns of text regardless of the scale factor.

Tested under Win7 and Win10. Win7 has the scaling behavior, but it's a little harder to find and requires logging the current user out.

[jblang]

Confirmed that it works correctly for me too on both Windows 11 at 150% and Windows 10 at 250%. Thanks for the quick turnaround!

Side note: my Windows 10 laptop has a 13" 4K display and the toolbar icons are comically small on this screen. Should I file a separate issue for that? I guess you'd have to find new icons or else just upscale them and they'd be blurry.

[jblang]

Screenshot from my laptop:

[fadden]

I think I'd need to draw or generate a set of larger icons. I don't know if there's a Win32 or MFC API that will do the upscaling automatically.

There's a related issue in the file viewer: the fonts for text documents are scaled appropriately, but images are still rendered at 1:1.

The correct fix for the toolbar is to use XAML-style vector art, but I don't know if there's a way to make that work with an old MFC app. Converted images should stick to integer scale factors, so could potentially be pixel-doubled for 175% and above.

[jblang]

OK... it sounds like a lot of effort. Up to you how you want to handle in terms of separate issues or continuing to work on this one, but I consider my original problem resolved so I'm fine closing this if that's what you want.