Leider ist der Eintrag nur auf Amerikanisches Englisch verfügbar. Der Inhalt wird unten in einer verfügbaren Sprache angezeigt. Klicken Sie auf den Link, um die aktuelle Sprache zu ändern.

I am playing Horizon Zero Dawn (by Guerrilla Games). Brillant game! I am having a great time with it.

When I learned (this Friday) in the Game, that the small Device Aloy is using is called „Focus“ and was produced by a Company called „Faro (Automated Solutions)“, I laughed so hard I had to pause the game.

farofocus

This is even more funny, since I am working at FARO, and I am working on the software for our Focus laser scanner.

What kind of coincidence is this?

Und hier sind wir. Am Ende von 2017. Im Vergleich zu 2016 war das ein richtig gutes Jahr. So viel ist passiert. Tatsächlich ist so viel passiert, dass ich praktisch gar keine Zeit für diesen Blog gefunden habe. Die Webseite scheint tot. Sie scheint! Sie ist es nicht. Sie ist nur … öhm … langsam.

Wie dem auch sei. Die wichtigste Änderung für mich war ganz klar, dass ich die universitäre Welt endgültig verlassen habe. Im Frühjahr bin ich bei der FARO Scanner Production eingestiegen, einem High-Tech-Unternehmen, welches Laser Scanner baut, inklusive der dazugehörigen Software. Natürlich bin ich wegen der Software dazugestoßen, genauer, wegen den Visualisierungs- und Renderingfunktionen. Bis jetzt fühle ich mich in meinem Job saumäßig wohl. Meine Kollegen und Chefs sind alle super, die Arbeit ist super interessant, herausfordernd und macht Spaß! Gegen Ende des Jahres wurde ich zum Team-Leiter der Visualisierungsgruppe befördert. Dadurch gibt es natürlich noch mehr zu tun, aber es ist auch interessanter. Ich freue mich wirklich auf die Herausforderungen und Möglichkeiten die im kommenden Jahr 2018 auf mich warten.

WinForms De-Blurred

Leider ist der Eintrag nur auf Amerikanisches Englisch verfügbar. Der Inhalt wird unten in einer verfügbaren Sprache angezeigt. Klicken Sie auf den Link, um die aktuelle Sprache zu ändern.

The Problem

We have projects working with WinForms GUIS. Different Developers work with different Computers, and these have different DPI settings. Every time the Project is opened on a system with different DPIs the WinForms get scaled, which is painfully bad.

Solution Summary

  • Set in your Forms Designer: Font = MS Sans; 11px
  • In the Forms Ctor, after InitializeComponent, set: Font = SystemFonts.DefaultFont
  • Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness

Solution Details

mmconf_blurless
Make your WinForms GUI less blurry by being DPI aware

A modern Windows approach to High-DPI Displays

More and more Computers get equipped with High-DPI Displays, a trend I like very much. Pixels cannot be small enough. With modern Windows, however, GUI of older Applications get infamously blurry. This is due to Microsoft’s approach for backward-compatibility: applications will be rendered at their native DPI and scaled up to the system’s DPI. This way, the application does not need to know anything about DPI, but user controls will keep a decent size on any setting. While most people hate the blurriness of old GUIs on modern Windows, this approach does make a lot of sense:

  • Backward-Compatibility is instantly given, as nothing changes for the old Applications.
  • The users input experience is retained, as the GUI will keep its apparent size. (Just thing, if you’re old enough, of the original GUI of Winamp, where the buttons in the default skin were sometimes just a few Pixels in size.)
  • (last but not least) for new Applications, Developers hopefully get upset with the blurry look, that they actually invest some time, to do it right!

So, don’t claim it’s all Microsoft’s fault that the GUI of your applications look blurry. Truth is, you were just too lazy to do it right.

Why WinForms?

If you browse the internet in search for how to handle high-DPI settings with WinForms, you are bound to stumble upon a smart-ass telling you to switch to WPF. That person does have a point: WPF is designed to be a GUI for all resolutions. But, that person is also an idiot. Don’t bother discussing.

If you decided to use WinForms, then use WinForms. It is not deprecated, it is not legacy, it is not broken. There are good reasons to use WinForms. One, for example, would be the nice compatibility with Mono (Linux and MacOS). Another one would be compatibility with native GUI controls. Whatever your reason is, don’t let other people easily throw you off track.

If you’re not fixed on WinForms, but want to write a new Application for Windows, then have a look at WPF.

Why does Visual Studio Scale?

Normally Windows works at 96 DPI. That is, you need 96 pixels to fill up one inch of screen space. On a higher setting, let’s say 144 DPI, you need 144 pixels. So, either your GUI elements will look smaller, or your GUI elements must be larger to look the same. Modern graphical content is thus not described in pixels, but often in points (pt). Points are defined as 1/72 inch, that is in screen space, and not in pixels.

WinForms is not a modern GUI. All Elements are designed with pixels. However, higher DPI settings were present in Windows for a long time (accessibility feature). WinForms answers to this by having a mechanism to scale the whole GUI ‘manually’. If a scaling factor different from one is determined, all GUI elements, positions, sizes, etc., are multiplied by that factor, including the overall size of the window. By default, this scaling factor is determined comparing the Font settings of the form. Fonts are usually specified with a size in pt. Windows computes the font size in pixels based on the active DPI value. If WinForms now detects a mismatch between the pixel-based font sizes between design-time specifications and run-time evaluation, the form and all content is scaled. And this is exactly what happens in the Visual Studio Windows Forms designer.

Visual Studio does basically nothing at all. However, the font size evaluation is based on the system’s DPI setting. So on high-DPI systems, the font’s pixel size will be different from the stored design-time pixel size, and thus the whole form will be scaled accordingly. That is a good idea at run-time. I mean, that is the whole point of this mechanism. However, we are still at design time. The problem raises, because the Forms designer in Visual Studio actually runs the WinForms engine. As now all GUI elements change their sizes, the designer is informed (likely by the normal events) and adjusts all generated code to the new sizes and locations. This is, of course, ugly, painful and stupid, if you are going to continue the development on another machine with another, maybe, lower DPI setting.

Disable Scaling at Design-Time, Enable Scaling at Run-Time

What I am writing here is not a premium solution. It is the workaround I found for myself to work best.

The basic idea is to (manually) disable scaling at design time, and to (manually) enable scaling at run time.

I write scaling, but what we actually change is the Font!

Keep the Form’s AutoScaleMode = Font. That setting is correct and is not the problem at all. The problem is the automatically used font. It is the system’s default font, which specifies its size in pt. Again, a good idea at run time. What we change is the Font setting of the Form, to specify the size in pixels.

In the Designer, set the Font to: Microsoft Sans Serif; 11px

Windows default Font is Microsoft San Serif 8 pt. according to MSDN. Actually, it seems more like 8.25 pt. So this is 8.25/72 inch, which finally results in 8.25 * 96/72 = 11 pixel on a normal DPI system. That is why you set the font to this painfully small looking value. It is the right one! Now edit your GUI on all systems you have. Your Forms will not be scaled by Visual Studio any more. So, design time is fixed.

Now for the run time. That one is easy, too. All we need to do is to ‘reset’ the Form’s font to have its size specified in pt. again. The easiest way to do that is to reassign the system’s default font. Just set it in the constructor, right after InitializeComponent:

Font = SystemFonts.DefaultFont;

This, of course, only works if you are on a system where the system’s default font is as expected, and only if you do not change fonts for the controls inside your form. If you did change some control’s font, you specify the font with pixel size for design time and you update these at run time initialization to use pt.-based sizes again.

Scalable GUI Design

And that is that. If your application is already DPI aware, your forms will now scale nicely. That is, if you designed them correctly.

  • You should not mix docking-based and anchor-based design in the same form. That is bound to produce weird scaling issues.
  • You must use either, otherwise the controls will just randomly shift somewhere.
  • Be aware that the control might no longer fit into your Form, due to the maximum window size. Use flowing layout containers and auto scrollbars.

Enable DPI Awareness

All that, of course, only makes any sense if you enable DPI awareness for your application. There are basically two options:

Manifest-Segment I use:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
  </windowsSettings>
</application>

Code I use:

[DllImport("SHCore.dll")]
private static extern bool SetProcessDpiAwareness(PROCESS_DPI_AWARENESS awareness);

private enum PROCESS_DPI_AWARENESS {
    Process_DPI_Unaware = 0,
    Process_System_DPI_Aware = 1,
    Process_Per_Monitor_DPI_Aware = 2
}

[DllImport("user32.dll", SetLastError = true)]
static extern bool SetProcessDPIAware();

internal static void TryEnableDPIAware() {
    try {
        SetProcessDpiAwareness(PROCESS_DPI_AWARENESS.Process_Per_Monitor_DPI_Aware);
    } catch {
        try { // fallback, use (simpler) internal function
            SetProcessDPIAware();
        } catch { }
    }
}

Maybe, you know, that modern Windows can be even more complicated by per-monitor DPI settings. The idea is, that attached external screens have different sizes and resolutions, and should thus be handled with different DPIs. The good news is: this approach here works instantly with per-monitor DPI. When the form is dragged onto another monitor, the system automatically adjusts the font setting, as the font size is at run time specified in points. This automatically triggers a rescaling of the form. Wheee!

Als ich den Comic von xkcd hier gelesen habe kam ich ins grübeln. Ich lese xkcd gerne. Wenige Comics sind blöd, viele sind nett und einige sind brillant. Und diese letzten werde ich jetzt hier rebloggen, als verteiltes Archiv. ;-)

“If you can read this, congratulations—the archive you’re using still knows about the mouseover text”!
“If you can read this, congratulations—the archive you’re using still knows about the mouseover text”!
Digital Data [xkcd_1683]

Alles was ich gemacht habe, war auf den „Update“ Knopf in meiner WordPress-Installation zu drücken.

Der Server hat mitten im Updaten die Session zu gemacht. Der Installer konnte diese nicht wieder aufnehmen, reparieren oder irgendwas. Und ich habe meinen wertvollen Nachmittag damit verbracht meine Webseite mit allem Inhalt wieder aufzusetzen. Danke.

Und kommt mir nicht mit dass Open Source hier nicht schuld wäre.

Die letzten zwei Sonntag gab es keine Posts. Und das war Absicht. Die ganze Jeden-Sonntag-einen-Post-Schreiben-Idee war zwar irgendwie gut, hat aber nicht funktioniert. Viel zu viele Posts waren nur Lückenfüller ohne Inhalt. Das ist nicht gut und das darf so nicht weitergehen. Es bläht nur meinen Blog auf und bringt niemandem was. Und Aufblähen von irgendwas ist etwas was ich wirklich nicht leiden kann. Also wird es Zeit damit zu brechen. Mehr noch: es wird Zeit aufzuräumen!

Ich habe alle alten Lückenfüller-Posts gelöscht. Die braucht kein Mensch.

Exoworlds ist Geschichte. Die Idee für das Spiel trage ich seit der Schule mit mir rum. Es wird Zeit sie los zu lassen. Ich werde nicht die Zeit finden das Spiel in der Form zu realisieren die ich möchte. Ehrlicherweise muss ich sagen, dass ich da meine wenige Zeit lieber in andere Projekte investiere.

Konkret habe ich noch zwei laufende Projekte: MegaMol und SpringerJagd. Die beiden werde ich nach wie vor bearbeiten. Und im Dunstkreis dieser Projekte entstehen noch einige kleinere Tools.

Ich werde weiterhin versuchen regelmäßig zu posten. Aber ich mach keine Versprechungen mehr.

Morgen startet die erste Woche des Wintersemesters 2015/16 an der TU Dresden. Ich werde wieder die Vorlesung über wissenschaftliche Visualisierung halten. Zusätzlich betreue ich mehrere Studenten bei ihren Abschlussarbeiten (Bachelor, Diplom, etc.). Und natürlich brauchen auch die Vorbereitungen für das Tutorial zu Partikelvisualisierung auf der IEEE VIS viel von meiner Zeit. Es wird wieder eine anstrengende Woche.

Ich achte sehr genau darauf welche Fotos von mir im Internet im Umlauf sind. Und noch mehr achte ich auf private Informationen. Aber bei meinem aktuellen Urlaub gab es jetzt diese sehr günstige Gelegenheit: Wenn man kann, kann man mich durch die Web-Cam der MS Europa sehen (nein, ich bin nicht auf dem Schiff unterwegs).
MS-Europa-Webcam

Ich bin ein Microsoft-Fan-Boy. Das gebe ich gerne zu. Aber eins ist klar, die Jungs aus Redmond kochen auch nur mit lauwarmem Wasser. Und für Betatests habe ich keine Zeit und keine Geduld.

Diese Woche habe ich meine drei PCs auf Windows 10 hochgebügelt. Alle Rechner liefen vorher mit Windows 8.1, installiert mit dem gleichen Image und benutzt vor mir in etwa der gleichen Art und Weise. Daher fand ich es schon ziemlich beeindruckend, dass die Upgrade-Installation von Windows 10 aus demselben Image auf den drei Rechnen zu komplett unterschiedlichen Ergebnissen führte:

Mein Arbeitsplatzrechner hat nach dem Upgrade die Icons zu fast allen installieren Programmen vergessen. Ein Ergebnis der Tatsache geschuldet das ich den überflüssigen Installations-Cache von meiner zu kleinen SSD auf eine normale Platte verschoben und anschließend zurückverlinkt hatte. Den Link hat der Upgrade-Installer zur Sicherheit mal gesprengt. Man weiß ja nie.

Auf meiner Surface Pro 3 hat mich Windows 10 nach der Installation damit begrüßt, dass es mir erzählt hat welchen Funktionen ich doch alle hätte nutzen können, wenn ich eine Touch-Eingabe hätte. … Wut? Immerhin, nach zweimaligen zusätzlichen Neustarten hat sich dieses Verhalten etwas normalisiert. Nur dass die Notiz-Taste des Stifts sich partout nicht auf OneNote mappen lässt, sondern unveränderlich auf die nutzlose OneNote-Imitat-App verweist, nervt ganz schön.

Zu guter Letzt, auf meinem privaten PC, hat eigentlich alles funktioniert. Mit der einzigen Ausnahme, dass mein Antivirus deinstalliert wurde. Warum auch nicht. Immerhin hat es bei den anderen beiden Rechnen ja auch ohne Deinstallation direkt einfach funktioniert, da kann man ja hier mal eine Ausnahme machen.

Soweit dazu. Bisher macht Windows 10 einen Ok-Eindruck. Nur wenig nervt, nur wenig scheint echt verbessert, nur wenig scheint verschlechtert. Das wird schon, aber ein echtes Powerfeature vermisse ich.

P.S.: Und Microsoft kann nicht zählen! vgl: Visual Studio 14

Ich als Visualisierer wissenschaftlicher Datensätze kriege diese häufig in Form von beliebig strukturierten Textdateien. An sich nicht schlimm. Der erste Schritt ist dann eben eine initiale Konvertierung in ein schnelles Binärformat für die visuelle Analyse. Doch damit stehe ich immer wieder vor dem Problem eine 11 Gigabyte Textdatei verstehen zu müssen (Ich übertreibe nicht!). Da die Datei ja doch recht konsistent ist, geht es im Endeffekt immer nur um die ersten paar Zeilen und die letzten paar Zeilen. Dazwischen sieht ja doch meist alles gleich aus. Was ich also brauch sind die üblichen Linux-Befehle „head“ und „tail“. Nun bin ich aber ein Windows-Benutzer. Was nun also? Die Powershell hat die Antwort:

gc log.txt | select -first 10 # head
gc log.txt | select -last 10 # tail

Gefunden hab ich das auf: http://stackoverflow.com/a/9682594 (wo auch sonst)

Zumindest diese Variante von „head“ ist ausreichend schnell für meine Dateien. Ich bin zufrieden.