Changing DPI scaling

[llevier]

Hello,

First of all, thanks for this work ! I have an old Chuwi HI13 tablet, great for comics, but painful with the old Comicrack.

I would appreciate a new feature : ability to have bigger fonts for all sof(ware (menu + sub menus + popups). I am exclusively using Comicrack as a tablet and with a 3000x2000 resolution, text is really small :-(

Bigger menus icons (stack etc) would also be appreciated :-)

Thanks !

Brgds

[maforget]

I have heard feedback about something like that. Problem is that just changing the text size alone isn't enough, you need to scale everything. This already exists, the program already scales the UI based on your DPI scaling. A 13in screen with that big a resolution would require some scaling to work with windows. If you still haven't I would suggest you boost your scaling in windows, the program will scale accordingly. There are also compatibility settings you might try.

But even then this is a winforms program, it isn't that good with various screen density like Android apps are. It's not a coincidence that Microsoft started using new frameworks and redoing windows UI when they started pushing windows 8 and tablets.

It might be possible to have the DPI scaling be overridden by a user setting, but I don't know if it would fix your problem, especially if you are already using scaling in windows. Since higher resolution screen are more affordable these days it might be something to look into, but without using such a screen myself it's a bit hard to test and gauge the effect.

[maforget]

I've just discovered something, the Original ComicRack was supposed to be DPI Aware. So when I was creating it I added the relevant tag to the manifest saying to windows to not scale the program that the program itself would take care of it. Testing it by changing the scaling in windows without that entry would result in very ugly result as you can see in the first image in this wiki entry.

But going back to the original ComicRack, it looks the same distorted way. Checking the original binaries, there never was a manifest with the original. So that was the solution it used, leave it like it is so that windows scales the text and scale the rest of the components in code. So that might explain why in this version the text seems so small.

Can you compare with the original ComicRack if there is a big difference in text size? Can you post some comparison screenshot using different settings (windows scaling/compatibility)?

It seems that windows scaling stops at 175% scaling. Your screen seems to have 267dpi, so that would mean that even at 175% scaling you are still looking at smaller text than intended (around 60%). Although you can additionally change the text scaling manually in windows.

It seems they are now better ways for scaling in .NET Framework 4.7 even support for per Monitor. So a better DPI scaling might be in order.

---

Here are some docs for my future self to refer to: https://stackoverflow.com/questions/74983429/windows-system-dpi-getdevicecapshdc-logpixelsx-y-vs-getdpiforsystem => This is what CR uses. https://learn.microsoft.com/en-us/windows/win32/learnwin32/dpi-and-device-independent-pixels https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows https://learn.microsoft.com/en-us/dotnet/desktop/winforms/high-dpi-support-in-windows-forms?view=netframeworkdesktop-4.8 https://learn.microsoft.com/en-us/dotnet/desktop/winforms/automatic-scaling-in-windows-forms?view=netframeworkdesktop-4.8 https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/winforms/windows-forms-add-configuration-element

[llevier]

Hello I understand the global issue. Agree increasing the DPI value might help, I'll try to follow. However, increasing the DPI also has its global effects : bigger icons, text in tablet mode (out of Comicrack itself) etc. At the moment, Windows is at his maximum and all applications (lets use a classic browser only as reference) already provide quite big fonts and typing zone sizes. Same for virtual keyboard.

So the need is really focused on ComicRack itself. Proposing a workaround : preferences offers to select the font or just multiple sizes of the font. Possibly the size just above count solve the need with reduced impact (if any) on display ? You could put that only in the preferences source file as a test ? This way reduced changes and I can test notepading the preferences file and feedback ?

Thanks

[maforget]

It's not as simple as changing a setting, the text is specified in a lot of place. Having these all scaled with a central setting would take a lot of work, when it really should be taken care by windows. I also need to think about the rest of the interface, just scaling the text would result in very weird results. Also some of the interface is scaled relative to the font, so scaling the fonts will scale the rest of the UI (or part of it) so that the font are the same size relative to the rest.

Other programs might use other framework, but this project is built from old school windows screens and it probably will never be up to par with newer framework. It still doesn't support newer mode like Per Monitor, but it should still be scaling with windows settings, like the other apps do. So if the text is acceptable in others you should have a similar experience.

If the text is too small wouldn't everything be also too small, that means the menu, buttons, logo, etc. It would help if you posted screenshot, mentioned the various setting you tried, like compatibility settings for ComicRack alone (Do try this one before anything). There are also Text Size scaling in windows, independent from DPI scaling. If you used Custom settings it may result in the program not determining the scaling correctly, I did tests a long time ago and some registry setting would result in not detecting the DPI increase and never scale.

Like I mentioned there are changes that can be made that might have better scaling. I can't really check or test without having a 4K monitor, which won't happen, I don't think it is worth it for the money required to drive such a monitor (just the GPU alone).

[maforget]

Using this issue for potentially updating scaling to DPI.

Currently scaling is done using Font, like the above reference state there are better scaling with newer versions. It would require to change the AutoScaleMode to Dpi, but also require a higher DPI monitor than I have to test properly. Working by changing the DPI to 150% isn't a a feasible way to work.

[gman-comicdb]

I'm also interested in improving how DPI scaling is handled. +1 "low priority". Not familiar with AutoScaleMode.

My desktop screens are 1440p; I have mobile (Windows) devices with a high pixel density that could probably help in the 200-300% range.

Some related code

https://github.com/maforget/ComicRackCE/blob/7d306823cc71b1312d059a16036b4c7f1c341cc9/ComicRack/app.config#L10

https://github.com/maforget/ComicRackCE/blob/7d306823cc71b1312d059a16036b4c7f1c341cc9/ComicRack/app.manifest#L57-L59

https://github.com/maforget/ComicRackCE/blob/7d306823cc71b1312d059a16036b4c7f1c341cc9/ComicRack/Program.cs#L1118-L1124

https://github.com/maforget/ComicRackCE/blob/7d306823cc71b1312d059a16036b4c7f1c341cc9/cYo.Common.Windows/Forms/FormUtility.cs#L79-L99

Some quick notes

• [config] Is there any requirement/advantage to appsettings.json?
  • [net-6+] Similarly, ApplicationConfiguration.Initialize() (e.g. apparently this is used by the designer; not sure if other methods are)
• Not sure what's actually being applied, and how this interacts with Compatibility settings (dependancies/ conflicts)
• Should review FormUtility Scale method usage.
  • Are they being applied consistently, are they being applied when required, are they being applied even when not required?
• [touch] From memory, regions were not scaled (tangelial - the whole Windows 7 touch needs to be replaced)
• Review, test etc (I have not looked at this in the app or the code)
  • Per-monitor settings
  • Handling DPI change
  • Font.. default, hard-coded, designer v app (if that matters - apparently it changed at some point)

[maforget]

It has been a while so I might be mistaken on some stuff.

But from what I remember the current AutoScaleMode is set to Font, so the OS scales the controls based on the Font of the text. The rest of the controls are done manually by using the DpiScale and multiplying everywhere. I had a PR for my Bédéthèque Scraper plugin that just added a utility that went over all controls and just switch the scaling to Dpi and it seem to work well.

If you read the above references, it seems like Dpi scaling was updated and is now much better since the last update by cYo, which might be why it wasn't use before. So the idea was to change everything to Dpi and see how it behaves. It might require removing the usage of DpiScale at these places. Hence the testing to see the behavior.

I am unsure about the usage of SetProcessDPIAware, but also this seems something that has changed. There are new DpiAware/DpiAwareness options in the manifest that didn't exists before, so I am guessing that that call may be redundant and the manifest should be enough. It might also be required to be either update or remove that call if it is an old call that might not support new setting like PerMonitorAware or give contradictory values to the OS.

For compatibility setting from what I remember (also been a while so need confirmation) the manifest tells the program if it supports scaling and if the OS or program should do it. The setting just overrides that value and let's the OS do it's own like it would. I also believe that the System (Enhanced) override specifically uses the new Dpi scaling and is a good preview of what it would look like.

But like I said there would need to first test how changing to Dpi behaves and if it takes into account things like different monitors automatically (I wouldn't bet on it) or if that is something that needs to be done internally whenever a window is switched to a new monitor. So something like having multiple monitors with various size/Dpi would be needed to fully test.

Edit:

I will just put this here, since I had that in a stash since forever. They are the manifest changes so the program is PerMonitorAware.

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness>
      <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
    </windowsSettings>
  </application>

[gman-comicdb]

I had a look and your memory is right AutoScaleMode is set to Font in most cases. I've skimmed through the docs a few times but I don't have the context (of having worked with trying to scale UI) to get the significance; I'll have to re-read them when I start experimenting with different DPI settings.

The reason I looked into it was because PreferencesDialog and ProgressDialog were not scaled correctly in modern .NET and I was trying to figure out what changed. This was because they used AutoScaleBaseSize, which is broken since ~.NET 6 or so. They do not set AutoScaleMode, so assume using AutoScaleMode.None

From what I can gather, specifying PerMonitorV2 in the manifest helps but there is a lot of work required to correctly handle scaling. It seems to mostly boil down to not officially being supported on 4.8. The consequence is hacky Win32 calls and manually handling DPI-related messages, such as going between monitors with different DPI settings as you hinted at. (or DPI changing whilst the app is running). Modern .NET supports scaling on the control level so abstracts the headache away.

Another things - lack of multi-DPI image support in the Resources manager means images either need to be scaled or manually changed.