Dolphin is not High DPI aware

[blairmcg]

As Dolphin is not High DPI aware, it relies on Windows performing bitmap scaling when rendering at magnifications other than 100%. This causes fuzzy rendering of text and poorer quality images. Unfortunately, implementing full multi-monitor DPI awareness is a non-trivial undertaking.

[andygraham]

Under Windows 10 Creators Edition setting the Dolphin7.exe Properties -> Compatibility -> Override high DPI scaling option to System (Enhanced) vastly improves the appearance of Dolphin Smalltalk, as it does most Windows Forms/MVC/ATL/GDI based applications.

[blairmcg]

Thanks @andygraham, that is indeed a massive improvement - quite noticeable on a 4K device. According to the docs it only works for GDI stuff (not GDI+), but for most purposes that doesn't matter I suppose. Now we just need to work out whether this can be specified in the app manifest.

[andygraham]

There are two things that I have noticed that are not quite right with System(Enhanced) scaling on my Surface Studio (4500x3000) at 200% scaling. They probably count as Windows scaling bugs but I can live with these for the immense improvement in appearance, and Microsoft have promised further future improvements in scaling legacy applications.

1) The height of Message boxes is not calculated correctly and horizontally cuts off the bottom line of text if there are no following new lines to pad the content vertically. My WinForms apps show this so I assume that Dolphin will exhibit it as well.

2) I've only seen this (so far) in Dolphin Smalltalk. The cursor positioning is being calculated wrongly in the search text box in the Class Browser. Hold down the 'i' key and see the cursor fall behind as more 'i's are added. Clear it and then hold down the 'c' key and watch the cursor advance beyond the actual entered text.

[blairmcg]

I don't see any issues with the message boxes in Dolphin on a 4k device at 100%. I'm not sure why there would be in WinForms, since I assume it is just wrapping the standard Windows MBs like Dolphin does. Maybe it is to do with the unusual aspect ratio of the Surface Studio. Number (2) is much more of a problem, particularly since this also applies to the browsers and workspaces. It is related to the use of the Scintilla editor control, which draws its own cursor and so presumably has a bug in it related to its calculation of character widths. It doesn't seem to be much of a problem with the usual mixed text in some code, but I can imagine that there might be times when it would be inaccurate and cause significant editing frustration.

[andygraham]

1) Do you mean 100% scaling? I would expect that to work OK, I suspect it is the 200% scaling that is magnifying a slight error in calculation over several lines. It takes about eight lines without a trailing newline to exhibit the problem. I've tried to see it in Dolphin but being a Smalltalk neophyte I've totally failed to make string incorporating new line characters :(. In any case it is easy to work round for your own message boxes by adding some trailing new lines.

2) Perhaps it is the version of Scintilla. Notepad ++ uses Scintilla and doesn't seem to exhibit the same problem on my system.

[andygraham]

2) This is not a Scintilla bug but seems to be a Windows scaling bug. I have a Basic language IDE that I maintain which uses the ActiPro Syntax Editor and have noticed that it behaves the same on non-fixed width fonts. I hadn't noticed it before now because I use fixed width Consolas as my editing font. I suspect Windows is reporting the wrong pixel length for a text string and further suspect that it might be some sort of rounding error from calculating the scaled length using integer values rather than floats.

So I have changed

Tools Options -> Inspect Options -> Workspace -> defaultFont -> Consolas 10pt SmalltalkSearchPresenter.Default view -> font -> Consolas 8pt

and it looks fine under System(Enhanced) scaling.

[blairmcg]

@objectarts did a lot of basic work to enable this a looonnng time ago (see e.g. View>>#resolutionScaledBy:), and consequently just adding a dpiAware attribute to the exe manifest for the launcher works surprisingly well. Seeing how crisp it looks really does make the existing OS scaled arrangement look very blurry.

Some remaining issues identified so far:

1. Default window sizes are not scaled, so tools open a the original extent, which is likely to be too small at high DPI.
2. Toolbars don't scale. This requires choosing a different bitmapSize to remap from the 96-dpi design extent to the actual extent. E.g. at 125%/120dpi, the default 16x16 bitmap size should result in 20x20 icons being used) Any embedded views, such as the search box in the Dolphin browser toolbars, also need to be rescaled.
3. TreeView icons are not scaled (again, requires choosing a different physical icon size to the logical/design size)
4. ListViews do seem to scale icons correctly (e.g. at 120dpi 20x20 icons are used instead of the default 16x16 at 96 dpi), but not in Dolphin implemented 'thumbNail' mode. This is more noticeable at higher magnifications, e.g. at 150% the thumbnails need to be 96x96 rather than 64x64.
5. ListView fixed width columns recaling does seem to be implemented, but there are still issues with some columns being too narrow at scales > 100%.
6. Status bars appear not to be rescaled?
7. In a confirmation MessageBox the question mark icon is a scaled up smaller icon and looks poor. Also I notice this is not the latest question icon?
8. Splash screen does not rescale.

This is for basic (not per monitor) high DPI awareness where the DPI of the primary monitor is used for everything. This is adequate for the common case of having a single high DPI monitor with scaling (e.g. a 4k monitor at 125% or 150%), or a matching sets of monitors with the same logical DPI. Where monitor DPIs are different (e.g. an external monitor connected to a laptop set up with different scale in the display settings), the system scales from the primary monitor for windows placed on the other monitor(s). In the basic mode, changes of scale in the display settings are rescaled by the OS for running applications too, which means things do not rescale properly until Dolphin is restarted at the new resolution. I am looking at enabling per-monitor High DPI in Dolphin 8, but this is much more complicated and there is too much churn for Dolphin 7. The basic system-wide DPI awareness mode is a distinct improvement, and for many set-ups and usage scenarios not noticeably different.

[blairmcg]

Fixed in 7.2.0 release. In the end I decided to do full per-monitor support in Dolphin 7. It introduces a significant amount of churn, but turns out to be necessary to provide a satisfactory experience for a number of reasons. Port to Dolphin 8 is pending.

[blairmcg]

Both D7 and D8 are now per-monitor DPI aware, and blimey it was surprisingly complicated to do.