Fix font aliasing - Githubissues

Otiel commented 5 years ago

I'm not sure if it's aliasing or something else but some fonts look choppy or clipped.

For instance, on this context menu, all characters of the same "value" are not rendered the same way and some are easier to read than others (look at the r, l, F...):

Or on this screenshot, look at the commit messages and paths:

Are the fonts supporting ClearType?

DanPristupov commented 5 years ago

Are the fonts supporting ClearType?

Yes, on 99% of systems (https://github.com/ForkIssues/TrackerWin/issues/12), but there are still some problems sometimes.

What OS, screen resolution, DPI?

Otiel commented 5 years ago

Windows 10 1809 (Build 17763.134), 1920x1080, 100%

DanPristupov commented 5 years ago

Do you have a single monitor or multiple ones?

Otiel commented 5 years ago

Two monitors, both 1920x1080.

Otiel commented 5 years ago

@DanPristupov Could you try to set TextOptions.TextFormattingMode = "Display" on small fonts (context menus, commits...) and see if the text looks clearer?

Have a look at this resource. He recommends the following:

You should use the value of Ideal, except for the situations listed below.

Set TextFormattingMode to Display when all of the following is true:

The FontSize of the text is 14 or less (small text)

Text is not being transformed (scaled, rotated, translated)

The exact shape of the glyphs is not critical (e.g. for some graphic design scenario)

Otiel commented 5 years ago

@DanPristupov Did you had a chance to test this?

vitalyster commented 5 years ago

The problem is on 96dpi screens and TextOptions.TextFormattingMode = "Display" definitely fixes this

DanPristupov commented 5 years ago

I setup Windows 10 on an old laptop with 96 DPI and going to investigate that.

SylwesterZarebski commented 5 years ago

Please fix this, all texts look awful because of greyscale AA.

Otiel commented 5 years ago

Tabs title even look blurry.

SylwesterZarebski commented 5 years ago

Is there RenderTransform used in any place? RenderTransform mixed with LayoutTransform (for zoom) breaks proper font rendering. Also if RenderTransform is used in any global Style it could be a cause of this.

It looks like interface at 100% is not really 100%, but scaled down from some bigger size.

Another thing is intermediate render targets (Effect, OpacityMask, VisualBrush, DrawingBrush, Clip, Opacity etc.), which also blocks ClearType rendering, but it looks like it is not a cause (RenderOptions.ClearTypeHint="Enabled" would force proper rendering on TextBlock, but i could not force to do that using WPFSnoop).

Otiel commented 4 years ago

@DanPristupov any chance to have this fixed soon? Some texts are really painful to read.

vitalyster commented 4 years ago

There is an another issue with both hi-dpi and 96-dpi screens - missing per monitor dpi awareness, texts became blurry when Fork dragged from hi-dpi screen to 96 dpi screen, when connected from 96dpi RDP session to Fork started on hi-dpi screen, etc.

ma-bjo commented 4 years ago

@DanPristupov Are you familiar with the SnapsToDevicePixels property that is available on most WPF controls? It usually works quite nice in order to get rid of the usual blurriness that WPF applications otherwise suffer from. We usually set it on the top level Form so that it affects the entire window.

Overriding the smoothing mode (ClearType etc.) during rendering is bad, applications should always respect the user's preference and go with the current mode configured in Windows.

DanPristupov commented 4 years ago

We use SnapsToDevicePixels of course. The problem is that on all my computers (200 DPI, 96 DPI, TV) fonts look sharp.

Otiel commented 4 years ago

What about TextOptions.TextFormattingMode?

vitalyster commented 4 years ago

@DanPristupov what is the 96 dpi screen (model, vendor, scaling factor) you are using? Anyway, you will not loose anything if Display text formatting mode will be applied but it will help a lot of people :)

ma-bjo commented 4 years ago

The fonts look sharp on my machine as well, regular monitors with default dpi and no scaling. Could it be a problem with a corrupted WPF Font Cache on the machines that have this issue? That service has been known to cause blurry fonts on some machines, so maybe @Otiel can try clearing his cache?

SylwesterZarebski commented 4 years ago

[@ma-bjo]

The fonts look sharp on my machine as well, regular monitors with default dpi and no scaling.

Hmm... Your images from issue #777 suffers from the same ugly greyscale AA. Maybe You are just used to this ugly AA behaviour, but it is very noticeable for me.

Otiel commented 4 years ago

Could it be a problem with a corrupted WPF Font Cache on the machines that have this issue? That service has been known to cause blurry fonts on some machines, so maybe @Otiel can try clearing his cache?

This? https://winaero.com/blog/rebuild-font-cache-windows-10/

ma-bjo commented 4 years ago

Yes, that's the cache I was referring to. But as @SylwesterZarebski pointed out I do see what you meant also on my machine - the fonts are not using ClearType as they should. So please disregard my latest statement.

vitalyster commented 4 years ago

@ma-bjo

applications should always respect the user's preference and go with the current mode configured in Windows.

All applications which uses DirectWrite/Direct2D font rendering (as opposite to GDI rendering) are ignore ClearType "user preferences" by default and this is the problem described there. With old GDI apps we can configure to use grayscale antialiasing (uncheck " enable ClearType") or subpixel antialiasing (check "enable ClearType") globally in Windows. WPF uses DirectWrite and it uses grayscale AA by default. Subpixel AA in DirectWrite can only be enabled programmatically (D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE in C++, "TextFormattingMode=Display" in WPF).

SylwesterZarebski commented 4 years ago

@vitalyster : What? I've written few WPF apps and all of them uses cleartype/subpixel AA by default. TextFormattingMode=Display is not necessary for most situations. I'm using Ideal for all apps and mostly it is subpixel AA.

vitalyster commented 4 years ago

@SylwesterZarebski default WPF app without Display formatting mode looks exactly as Fork

ma-bjo commented 4 years ago

Whether fonts "look sharp" or "look blurry" can be very subjective. The easiest way to make sure is to take a screen dump and zoom in on the text using Photoshop or similar. If ClearType is used in the text rendering, there will be colored pixels also in grayscale text, but when (incorrect) font smoothing is used there is only grayscale pixels.

I just did that on Fork and cannot see that ClearType is used anywhere even though that is my preference in Windows.

ma-bjo commented 4 years ago

@SylwesterZarebski default WPF app without Display formatting mode looks exactly as Fork

No, that is not true. I just tested by creating a new, empty WPF project for .NET Framework 4.8 and added a TextBlock to the default grid without changing anything. It renders in ClearType just as it should.

vitalyster commented 4 years ago

@ma-bjo

.NET Framework 4.8

Maybe that was changed recently, I will try it now. In this case we just need Fork built on 4.8 (and it also should fix per monitor dpi awareness too)

DanPristupov commented 4 years ago

We still use .Net 4.6.1 (.Net 4.6.2 will be used in the upcoming Fork 1.50).

ma-bjo commented 4 years ago

I rebuilt my test project for .NET 4.0 and it still uses ClearType as expected. Still running on 4.8 of course, but that is true also for Fork om my machine.

vitalyster commented 4 years ago

text Net 4.8 does not change anything, still need "Display" to see "crisp" text on 96DPI/100% scaling and still "blurry" without it (second block, Fork looks like that). Both blocks looks great on hidpi screen.

ma-bjo commented 4 years ago

@vitalyster Both text blocks in your example are using ClearType, so this is not the same issue as in Fork where ClearType is not being used at all. (Zoom in on the picture to see it.) But I agree with you that the first block is subjectively more readable.

Otiel commented 4 years ago

More tests:

Zoomed in:

SylwesterZarebski commented 4 years ago

Setting TextFormattingMode=Display may bring back some contrast as seen above, but do not fix AA to be subpixel (although i have one or two cases when it works). Most greyscale AA is coming from transparency of grid or background. When background is solid and grid (or other) is not transparent, WPF should display subpixel/cleartype AA.

SylwesterZarebski commented 4 years ago

Also no subpixel AA on 1.50. Only menus inside have proper (system based) AA.

DanPristupov commented 4 years ago

We are investigating this issue.

@ma-bjo thank you very much for the the info. Now we can clearly differentiate blurry and sharp texts 👍.

@Otiel thank you for the tests.

It turned out that the problem is caused by a custom window chrome. It can be reproduced even in a simple project. Here's an example:

CustomWindow.xaml:

<local:CustomWindow x:Class="WpfApp5.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:WpfApp5"
        Title="MainWindow" Height="450" Width="800">
    <StackPanel>
        <TextBlock FontSize="14" Text="Lock access to jobprofile events" Foreground="#222222"/>
    </StackPanel>
</local:CustomWindow>

CustomWindow.cs

public class CustomWindow : Window
{
    public CustomWindow()
    {
        WindowChrome.SetWindowChrome(this, new WindowChrome());
    }
}

I will share more info when we find how to fix this.

Update: looks like a bug in WPF: https://social.msdn.microsoft.com/Forums/vstudio/en-US/61242512-92c9-44ab-b59d-5f2c996d8ec9/windowchrome-and-textoptionstextformattingmodequotdisplayquot?forum=wpf

SylwesterZarebski commented 4 years ago

I wonder what Visual Studio is using to render its window. I'll try to find...

vitalyster commented 4 years ago

I have added the following:

UseLayoutRounding="True"
RenderOptions.BitmapScalingMode="NearestNeighbor"
SnapsToDevicePixels="True"
RenderOptions.ClearTypeHint="Enabled"

( + TextOptions.TextFormattingMode="Display") And custom window now display text correctly

vitalyster commented 4 years ago

def - default chrome customrounding - custom chrome Looks absolutely identical after fixes

DanPristupov commented 4 years ago

Hi,

We made a build with many DPI-related changes. Could you try it and tell if you can see improvements?

The new version is available here as a zip archive (https://cdn.fork.dev/prerelease/Fork-1.50.5.zip). You need to extract it somewhere and run fork.exe.

Otiel commented 4 years ago

Looks better and easier on the eyes! 👀

It seems that your changes haven't been applied everywhere (yet?) though (for instance, on the File History window).

Thanks for working on this. 👍

DanPristupov commented 4 years ago

@Otiel thank you!

It seems that your changes haven't been applied everywhere (yet?) though (for instance, on the File History window).

We will check the File History and Blame windows.

Does the diff control look properly?

Otiel commented 4 years ago

Does the diff control look properly?

It's still grayscale AA:

SylwesterZarebski commented 4 years ago

Thanks Dan for great work! Not many people bring back proper subpixel AA in these days :-).

DanPristupov commented 4 years ago

Offtopic: it's not directly related, but recently there was a great post you guys may find interesting: https://tonsky.me/blog/monitors/.

SylwesterZarebski commented 4 years ago

Article is so much about Macs and their scaling and font rendering may be very good, but Windows has so inferior scaling:

scaling is mostly unusable at other scales than integer ones (100%, 200% etc.), because system can't properly scale many programs (i.e. mmc.exe),
even on these properly working programs, fonts are improperly scaled to some weird sizes (eg. font 9pt is not exact 13.5pt at 150%, but some other - closer to 14pt) and what is worse, they are still hinted to full pixels which makes them distorted; it is very visible to any person which also works with graphics and/or print.

Also:

even 4K 27" monitor has clearly visible and better crispness with subpixel AA than greyscale AA,
there are almost no available monitors with bigger resolutions than 4K (ignore few ones which costs tens of thousands of $).
when someone also play games, he/she is tied to lower resolutions like WQHD or must buy very, very expensive GPU,

PS. 144Hz free/g-sync monitors gives more fun than higher resolution ;-).

vitalyster commented 4 years ago

1.50.5.0 is much better but still has issues:

1) only some views now have improved font rendering (commits history, tab titles). Most of other views still have "blurry" fonts: branch tree, commit preview pane, etc. Button panel still have icons which are not snapped to device pixels and they are blurry as fonts too. All of these issues are only for 96 dpi screen, 100% scaling. On 192dpi and 200% all fonts and icons still looks crisp.

2) Still no per monitor DPI awareness - when I drag Fork window from 96dpi monitor to 192dpi one - I have the same blurry fonts and icons even on hi-dpi screen!

DanPristupov commented 4 years ago

We created another build (1.50.6). https://cdn.fork.dev/prerelease/Fork-1.50.6.zip

There are many improvements everywhere (sidebar, diff text, windows, file history, blame etc). Could you try it tell if you see the difference and what is still blurry? Thank you!

Still no per monitor DPI awareness - when I drag Fork window from 96dpi monitor to 192dpi one

We can't fix this in the near future.

ma-bjo commented 4 years ago

Thanks Dan!

Now that more and more text is getting crisp I have started noticing that most icons seems to be half a pixel off as well, both in the sidebar to the left and the main toolbar at the top. Standard monitor, no high-dpi setting. It is mostly noticeable when there are straight lines in the graphics, such as for the folder icon for branches with / in them, and the icons for Changes, All Commits, Quick Launch and Stash.

This blurriness is also very prominent in lists and trees where file type, folder, and status icons are included, typically the lower parts of the Commit/Changes/File Tree tabs. For example, I imagine that the intention is that the ... and + Git status icons are squares with rounded corners, but the rounding is inconsistent and it looks irregular. They also have different sizes in the different tabs, so some of the blurring is most likely caused by scaling. There is room enough in all these lists to show a 16x16 px icon with no scaling.

I have also noticed that on the Commit tab, both the author and the commit is not properly aligned. The bold full name should have the base line aligned with the e-mail address that is shown immediately to the right of it. The e-mail needs to be moved 1px up for them to align properly. But now we are really taking details!

vitalyster commented 4 years ago

1.50.6 - much more improvements, but: context menu is blurry, commit pane is ok but its header with author and commit hash is blurry. All icons are blurry. Preferences window, quick launch window - blurry. I tried to switch dark and light theme and noticed that these problems are lesser annoying in Dark theme, maybe most of users are using Dark theme and that is why they did not see problem :)

SylwesterZarebski commented 4 years ago

@vitalyster: Which context menu? I have subpixel AA in left bar and history context menus, also commit hash below has proper AA. But, there is a but ;-). As @ma-bjo spotted, there is horizontal half-pixel off on everything and it is very visible on diff (i.e. letter m looks too bold).

What is not subpixel AA still:

filter field in left bar
keyboard shortcuts in menus
line numbers
filename/path in two-side diff
in Changes tab view mode menu
new branch window field
new tag window fields
commit subject and description (fields)
Unstaged Changes text and Stage button in Changes tab
Preferences window - almost all besides of diff preview and opened comboboxes entries

Button Expand All/Collapse All is partially over new changed commit files background.

fork-dev / TrackerWin

Fix font aliasing #63