Suche Tester für High-DPI

[Uwe Raabe]

Hallo zusammen!

Ich hatte es schon auf G+ gepostet, aber da ist ja auch nicht jeder aus der DP unterwegs. Daher nun auch hier meine Bitte um rege Testbeteiligung.

Nachdem Embarcadero ja irgendwie nicht richtig aus dem Quark kommt, habe ich mich entschlossen das Heft in die Hand zu nehmen und selbst an der VCL rumzuschrauben, um eine konsistente, stabile und vor allem Delphi-würdige Unterstützung von Multi-Monitor-Systemen mit unterschiedlichen DPI-Einstellungen bereitzustellen. Erste Tests haben schon sehr vielversprechende Ergebnisse geliefert.

Die angefügte ZIP-Datei enthält zwei ausführbare Programme: HighDPIRef und HighDPITest. Die Ref-Version ist mit einer Standardinstallation von Delphi 10.2.3 Tokyo erstellt worden. Bei der Test-Version habe ich ein paar Änderungen an der VCL gemacht und ein anderes Manifest verwendet. Beide Projekte verwenden dieselben Sourcen, lediglich der Suchpfad des Test-Projekts ist anders.

Das Ref-Projekt liegt auch im Source bei, wie auch eine neue Komponente TDPIAwareImageList, deren Sourcen im DynImageList-Ordner zu finden ist. Wer also das MainForm öffnen will, sollte vorher das entsprechende DynImageList-Package installieren. Allerdings hat das Package noch nicht die nötige Veröffentlichungsreife - das kommt aber noch.

Für die Tests wünsche ich mir eine breite Abdeckung unterschiedlicher Systeme (Anzahl Monitore, System-DPI, Monitor DPI, Windows 10, 8.1, 8, 7). Ergebnisse am besten in diesem Thread posten, dann haben alle was davon.

Wenn jemand noch weitere Bereiche kennt, in denen es noch Probleme dieser Art gibt, am besten auch hier posten. Ich werde versuchen, auch diese in die Patches mit aufzunehmen.

Ach ja, bevor es jemand versucht: VCL-Styles funktionieren auch mit diesen Änderungen noch nicht konsistent mit High-DPI. Das ist ein deutlich größerer Aufwand.

[BlueStarHH]

Erstmal danke, dass Du Dich mit diesem Thema beschäftigst. Es wird immer wichtiger.

Wenn ich es also richtig verstehe, soll die Darstellung von HighDPIRef und HighDPITest verglichen werden und Abweichungen hier gepostet werden?

[blawen]

Wunschgemäss ein paar Screenshot unter folgenden "Bedingungen"

- Win 10
- 4k Monitor
- Folgende Skalierungen wurden verwendet: 100%, 200% und 350%

[Uwe Raabe]

Zitat:

Zitat von BlueStarHH (Beitrag 1398309)

Wenn ich es also richtig verstehe, soll die Darstellung von HighDPIRef und HighDPITest verglichen werden und Abweichungen hier gepostet werden?

Eigentlich sollte die Funktionsfähigkeit von HighDPITest überprüft werden. Das HighDPIRef ist nur dazu da, den Unterschied zu der aktuellen Delphi-Version aufzuzeigen. Etwaige Fehler sollten also in der HighDPIRef auftauchen, in der HighDPITest aber nicht mehr.

[günni0]

Verstehe ich das richtig, dass du dich den Problemen der VLC annimmst?
Beispiel wäre hier, man baut eine Benutzeroberfläche mit einem 96 DPI-Monitor (100%) und unter 150% und 200& sieht es schrecklich aus?

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398319)

Verstehe ich das richtig, dass du dich den Problemen der VLC annimmst?
Beispiel wäre hier, man baut eine Benutzeroberfläche mit einem 96 DPI-Monitor (100%) und unter 150% und 200& sieht es schrecklich aus?

Genau! Die HighDPITest.exe im Anhang ist exakt so ein Beispiel.

[Der schöne Günther]

Ich hätte die beiden .exe-Dateien "Original" und "Modified" oder so genannt, unter den Abkürzungen hätte ich mir auch nicht vorstellen können was nun was ist ;-)

Getestet auf 125% (120 dpi) (2560x1440) und 150% (144 dpi) (1920x1080)

Ich habe nur eine Sache:
In den Ownerdraw-Menüs sieht der Pfeil schlecht aus.

PS: Ist das beabsichtigt dass die beiden TEdits im GridPanel1 eine für die Schriftart zu große Höhe haben? Vergleiche mit dem Edit1...

[günni0]

Welche Dateien müsste man denn übernehmen, um eine "fixed" VLC zu haben?
Aktuell handhabe ich es so, dass ich auf HighDPI prüfe (alles größer 96, weil 96 meine eigene DPI ist). Anschließend re-positioniere und vergrößere oder verkleinere alle Komponenten, die irgendwie falsch dargestellt werden. Fast vergessen. Scaled ist bei komplexeren Forms selbstverständlich auf False. Ansonsten drohen Schäden an den Augen bei der aktuellen VLC (übertrieben gesagt).

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1398321)

Ich hätte die beiden .exe-Dateien "Original" und "Modified" oder so genannt, unter den Abkürzungen hätte ich mir auch nicht vorstellen können was nun was ist ;-)

Perfekt kommt später :)

Das alles ist noch Work-in-Progress. Deswegen wird der Downloadlink in dem G+-Post auch öfter mal aktualisiert.

Zitat:

Zitat von Der schöne Günther (Beitrag 1398321)

In den Ownerdraw-Menüs sieht der Pfeil schlecht aus.

Zitat:

Zitat von Der schöne Günther (Beitrag 1398321)

Ist das beabsichtigt dass die beiden TEdits im GridPanel1 eine für die Schriftart zu große Höhe haben? Vergleiche mit dem Edit1...

In diesem Fall ist das Absicht. Die TEdits im GridPanel sind auf alClient mit AlignWithMargins gesetzt. Andernfalls würde man die Spaltenbreiten nur schwer erkennen können.

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398323)

Welche Dateien müsste man denn übernehmen, um eine "fixed" VLC zu haben?

Was verstehst du denn darunter?

Zitat:

Zitat von günni0 (Beitrag 1398323)

Aktuell handhabe ich es so, dass ich auf HighDPI prüfe (alles größer 96, weil 96 meine eigene DPI ist). Anschließend re-positioniere und vergrößere oder verkleinere alle Komponenten, die irgendwie falsch dargestellt werden. Fast vergessen. Scaled ist bei komplexeren Forms selbstverständlich auf False. Ansonsten drohen Schäden an den Augen bei der aktuellen VLC (übertrieben gesagt).

Kannst du mal so ein Form (dfm und pas) hier hochladen? Dann kann ich das mit der gepatchten VCL compilieren. Ich bin für jedes Beispiel mit einem Problemfall dankbar.

[günni0]

Möchte gerne anonym bleiben. Von daher geht das leider nicht.
Es ist aber im Grunde genommen eine modale Form, in der größe nicht veränderbar, ein TPageControl und eine TListBox drauf.
Zur Laufzeit werden die Tab-Titel ausgeblendet. Bei HighDPI (> 96) ist die ListBox dann irgendwo links oben im Nirvana (Versatz rund 10px).

[KodeZwerg]

Gibt es eine Demo die einem ein Skalierungs-Fehler zeigt und mit deinen Funktionen repariert bekommt?
Den einzigen Skalierungs-Fehler über den ich je gestolpert bin ist die korrekte Höhe der Titel-Leiste zu prüfen und im Code verwenden damit bei "Fixed" das Layout des Dialogs funktioniert und keine Scrollbars eingeblendet werden.

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398337)

Möchte gerne anonym bleiben. Von daher geht das leider nicht.

Und das geht nicht, wenn du die Dateien an deinen Post hier anhängst? Was steht denn in der DFM bzw. PAS so Identifizierendes drin? 8-)

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1398340)

Gibt es eine Demo die einem ein Skalierungs-Fehler zeigt und mit deinen Funktionen repariert bekommt?
Den einzigen Skalierungs-Fehler über den ich je gestolpert bin ist die korrekte Höhe der Titel-Leiste zu prüfen und im Code verwenden damit bei "Fixed" das Layout des Dialogs funktioniert und keine Scrollbars eingeblendet werden.

Mach doch einfach eine, die das Problem auf deinem System zeigt, und lade die hier als Anhang hoch (DFM und PAS genügt). Solange du keine Fremdkomponenten verwendest, die ich nicht habe, sollte ich das hier compiliert kriegen.

[KodeZwerg]

Falls Du das meinst, ein Beispiel basteln wo ein Titel-Leisten Skalierungs-Fehler erscheint, das kann ich Dir anfertigen, allerdings nur .dpr/.rc da per WinApi erstellt (ohne DFM) und ohne deinen Code integriert/gesehen zu haben.
Der Fehler reproduziebar Nachvollziehbar wäre, man stellt die DPI auf was höheres als 96 DPI und startet Anwendung = Dialog passt nicht mehr in das erstellte Window da die Titelleiste nun größer ist = Scrollbars erscheinen.

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1398344)

allerdings nur .dpr/.rc da per WinApi erstellt (ohne DFM)

Du scheinst da was falsch verstanden zu haben. Hier geht es um Modifikationen an der VCL zur korrekten Unterstützung unterschiedlicher DPI-Situationen. Wenn du die VCL gar nicht verwendest, können die Modifikationen ja auch nicht wirken.

Non-VCL ist also hier komplett out-of-bounds. In dem Fall empfehle ich ein intensives Studium der diesbezüglichen WinApi-Dokumentation.

[KodeZwerg]

Ich Versuche mal das WinApi nach VCL zu bringen, mal sehen was Delphi mit einer geänderten Skalierung anstellt, Verzeih die nicht Themen-Bezogene (nonVCL) Nachricht von mir. Komponenten werde ich ich, bis auf Panel & Button, nichts besonderes verwenden.

[günni0]

Mir ist gerade erst aufgefallen, dass sich 10.2.2 Starter wohl anders verhält als vorherige Versionen was HighDPI angeht.
Früher wurden meine Komponenten oft verschoben. Daher setzte ich Scaled erst einmal auf False und rief dann selber ScaleBy [ meine Original-DPI ] auf + weitere Änderungen von Hand.
Lasse ich das alles jetzt weg und stelle Scaled auf True, erhalte ich glas-klare Schrift (Windows 7, bei 10 ist es verschwommen), dafür ist sie kleiner. CheckBoxen und RadioBoxen sind aber entsprechend groß.

Ist letzteres das Szenario was unerwünscht ist?

[IRONIE]

Zitat:

Zitat von Uwe Raabe (Beitrag 1398341)

Zitat:

Zitat von günni0 (Beitrag 1398337)

Möchte gerne anonym bleiben. Von daher geht das leider nicht.

Und das geht nicht, wenn du die Dateien an deinen Post hier anhängst? Was steht denn in der DFM bzw. PAS so Identifizierendes drin? 8-)

Ich arbeite für die NSA und wir nutzen wir natürlich nur das Teuerste vom Teuren - also Delphi :thumb:
[/IRONIE]

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398348)

Früher wurden meine Komponenten oft verschoben. Daher setzte ich Scaled erst einmal auf False und rief dann selber ScaleBy [ meine Original-DPI ] auf + weitere Änderungen von Hand.

Eigentlich sollte die Standardeinstellung Scaled = True ohne weitere Maßnahmen bezüglich DPI-Änderung im Code ausreichen. Du kannst dir ja das aktuelle HighDPI-Projekt mal anschauen. Ich verwende für beide Compilate dieselben dfm und pas Dateien und da wirst du keinen Code finden, der irgendwas mit Scaled, ScaleBy oder irgendwelchen Controlgrößen oder -positionen macht. Der einzige DPI-Relevante Code steht in FormAfterMonitorDpiChanged und sorgt für eine Anzeige des aktuellen DPI-Werts.

Zitat:

Zitat von günni0 (Beitrag 1398348)

Lasse ich das alles jetzt weg und stelle Scaled auf True, erhalte ich glas-klare Schrift (Windows 7, bei 10 ist es verschwommen), dafür ist sie kleiner. CheckBoxen und RadioBoxen sind aber entsprechend groß.

Ist letzteres das Szenario was unerwünscht ist?

Kann ich jetzt so nicht sagen. Deswegen das konkrete Beispiel.

[günni0]

Ist mir bis heute ein Rätsel wie man ohne Änderungen an Scaled + irgendwas anderes, hier und dort noch was ... gute Resultate für 100% bis 200% Scale von Win XP bis 10 hinbekommt.

[KHJ]

Vielen Dank, dass Du dich darum kümmerst!!!

Es wäre schön, wenn Du auch https://quality.embarcadero.com/browse/RSP-18897 und https://quality.embarcadero.com/browse/RSP-18896 berücksichtigen könntest.
Im Anhang 2 Screenshots 1.Monitor mit 120 DPI und 2. Monitor mit 96 DPI. Die Menus sehen auch OK aus.

Karlheinz

[günni0]

Zitat:

Zitat von Uwe Raabe (Beitrag 1398332)

Zitat:

Zitat von günni0 (Beitrag 1398323)

Welche Dateien müsste man denn übernehmen, um eine "fixed" VLC zu haben?

Was verstehst du denn darunter?

Damit meine ich: du arbeitest ja gerade an irgendwelchen Dateien, um die DPI-Probleme aus der Welt zu schaffen.
Welche sind das sind, damit auch wir in unseren Kompilaten keine DPI-Probleme mehr haben?

Oder sendest du die Bugfixes einfach nur an Embarcadero für das nächste Update?

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398379)

Oder sendest du die Bugfixes einfach nur an Embarcadero für das nächste Update?

Mein persönliches Ziel ist, diese Fixes in der nächsten Delphi-Version drin zu haben. Das liegt allerdings nicht allein in meiner Hand.

Die geänderten VCL-Sourcen darf ich so zumindest nicht öffentlich weitergeben. Eventuell kann ich aber die Patches in Form von diff-Dateien publizieren (kläre ich gerade). Dann muss die jeder selbst auf seine VCL-Sourcen anwenden. Jedes halbwegs brauchbare Versionskontrollsystem sollte das relativ einfach ermöglichen.

Leider sind dabei alle außen vor, die mit Laufzeitpackages arbeiten, da man die nicht ganz so einfach neu compiliert kriegt.

[günni0]

Zitat:

Mein persönliches Ziel ist, diese Fixes in der nächsten Delphi-Version drin zu haben. Das liegt allerdings nicht allein in meiner Hand.

Die geänderten VCL-Sourcen darf ich so zumindest nicht öffentlich weitergeben.

Ok sehr gut. Jetzt weiß ich was los ist. Wollen wir mal hoffen, dass die sich darauf einlassen.
Einem geschenkten Gaul schaut man nicht ins Maul.

Ein Problem habe ich schon seit vielen Versionen. Kann ich aber leider nicht nachvollziehen oder eine Demo machen.
TForm, TMainMenu drauf und unter das Mainmenu eine TToolBar. Je höher die DPI, desto größer werden die TToolBar-Buttons, was logisch ist.
Die Bilder da drin bleiben aber leider klein. Füge ich von Anfang an größere Bilder ein, sind die Buttons so groß wie das Bild, was nicht gewollt ist.

[KodeZwerg]

@günni0: Diesen Fehler kannte ich, damals hatte ich eine Stretch Funktion dafür reingebastelt bis ich von Toolbars komplett weg bin.

[günni0]

erstes und einziges [OT]
Irgendwann gehe ich auch von der Toolbar weg. Muss nur noch eine schicke Alternative finden/bauen.
[/OIT]

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398384)

TForm, TMainMenu drauf und unter das Mainmenu eine TToolBar. Je höher die DPI, desto größer werden die TToolBar-Buttons, was logisch ist.
Die Bilder da drin bleiben aber leider klein. Füge ich von Anfang an größere Bilder ein, sind die Buttons so groß wie das Bild, was nicht gewollt ist.

Das Beispielprogramm aus der HighDPI.zip zeigt aber wie es funktioniert. Die Toolbars mitsamt Images passen sich an die aktuelle DPI an. Genau dafür habe ich die TDPIAwareImageList erfunden :-D

[günni0]

Ohne jetzt in die Demo zu gucken nehme ich an:
normale TToolBar und statt TImageList eine TDPIAwareImageList mit (großen) Grafiken bis sagen wir mal 48x48 Pixeln drin die dann skaliert werden?

[Uwe Raabe]

Zitat:

Zitat von günni0 (Beitrag 1398440)

Ohne jetzt in die Demo zu gucken nehme ich an:
normale TToolBar und statt TImageList eine TDPIAwareImageList mit (großen) Grafiken bis sagen wir mal 48x48 Pixeln drin die dann skaliert werden?

Nicht ganz: TDPIAwareImageList verlinkt zu mehreren normalen ImageLists mit unterschiedlichen Größen und sucht sich die passende aus oder skaliert optional auf die passende Größe. Skalieren ist aber halt nicht immer so brilliant. Deswegen empfehle ich eine entsprechend fein granulierte Staffelung der Bildgrößen. Das kann aber ja jeder dann selbst entscheiden.

[günni0]

Gerade die Demo aufgemacht.

Tolle ImageList! Aber durch diese neue Erkenntnis habe ich nun wieder Arbeit zu erledigen: alle Grafiken in verschiedenen Größen neu anlegen :stupid:

[jobo]

Ich habe keine Probleme festgestellt, die mit der Darstellung der Anwendung selbst zu tun haben.
Ausnahme (Win 7)
Wie verhält sich die Anwendung / OS (Win 7 / ..) beim Wechsel der Skalierung mit der Wahl der linken oberen Ecke.
Wird irgendein (Vor-)zustand der Fensterposition bei Mehrfachstart persistiert?
Gefühlt: nicht persisistiert
Erlebt: bei Wechsel von Normal/Standard auf Mittel mit CPU bzw. didizierter Graka im Laptop wird einmal unnötig weit unten positioniert, der Fuß der Anwendung ist nicht mehr im Bild und einmal wird so positioniert, dass die Anwendung noch vollständig angezeigt wird.

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1398470)

Ausnahme (Win 7)
Wie verhält sich die Anwendung / OS (Win 7 / ..) beim Wechsel der Skalierung mit der Wahl der linken oberen Ecke.
Wird irgendein (Vor-)zustand der Fensterposition bei Mehrfachstart persistiert?
Gefühlt: nicht persisistiert

Das Form hat Position = poDefaultPosOnly, womit Windows selbst für die Positionierung beim Öffnen des Forms zuständig ist.

Kannst du bezüglich der Ausnahme (Win 7) noch etwas konkreter werden? Z.B. welche Einstellungen, welche Schritte, was erwartest du und was passiert stattdessen.

Zitat:

Zitat von jobo (Beitrag 1398470)

Erlebt: bei Wechsel von Normal/Standard auf Mittel mit CPU bzw. didizierter Graka im Laptop wird einmal unnötig weit unten positioniert, der Fuß der Anwendung ist nicht mehr im Bild und einmal wird so positioniert, dass die Anwendung noch vollständig angezeigt wird.

Ich denke nicht, daß die Anwendung daran irgendetwas ändern kann. Während des DPI-Wechsels werden diverse Messages abgearbeitet und Umpositionierungen vom System vorgenommen. Wichtig ist, daß es am Ende wieder korrekt aussieht. Wenn ich bei einem meiner drei Bildschirme die DPI ändere, flackert es auf den anderen auch gehörig.

[jobo]

Alles bezieht sich auf Win7, was anderes habe ich noch nicht getestet.

Es ging nicht um Effekte die beim Wechsel selbst auftreten. Der Wechsel verlief so:
Einstellung ändern
Windowsdialog: "Wirksam nach Neuanmeldung"
Neuanmeldung
Neustart des Programms
Dabei hat Windows dann in einem Fall die Bildschirmposition wohl schlecht gewählt.

Ich wollte nur wissen, ob durch das Programm etwas persistiert wird (z.B. Fensterposition) oder ob Windows sich kümmert. Das tut es ja laut Deiner Aussage. Ein erneuter Test würde ja keinen Sinn machen, wenn die Fensterposition beim Beenden gespeichert und beim Neustart irgendwie berücksichtigt wird.

Der Effekt unter Win 7 war einfach, dass bei 2 verschiedenen Graka (Cpu und dediziert), die Positionierung beim Wechsel der Auflösung unterschiedlich erfolgte.
Hat dann wahrscheinlich gar nichts mit Deiner Anwwendung zu tun.

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1398498)

wenn die Fensterposition beim Beenden gespeichert und beim Neustart irgendwie berücksichtigt wird.

Das ist eine interessante Beobachtung. Soweit ich mich erinnern kann, berücksichtigt keines der bisher verfügbaren Verfahren (z.B. TRzFormState) die aktuelle DPI des Forms. Das ist vermutlich auch gar nicht so einfach konsistent umzusetzen. Muss ich mir mal durch den Kopf gehen lassen.

[jobo]

Das ist ja ein relativ exotischer Fall- der Skalierungswechsel an sich- besonders weil es hier nicht mal etwas mit unterschiedlichen Monitoren/Grakaausgängen zu tun hat, sondern darauf basiert, dass die dedizierte Graka des Laptops eine explizite "Zuständigkeit" für (d)eine Anwendung zugewiesen bekommt.
Was das Thema (schlechte) Fensterpositionierung angeht, gibt es viel banalere und häufigere Probleme. Ich habe bspw. auf einem (Doppel)Monitor die Taskleiste nicht auf Standardposition (unten), sondern links relativ breit (auf dem linken Monitor). Das wird von einigen Programmen nicht berücksichtigt, wenn man aus der Vollbilddarstellung auf Normal (wsNormal) umschaltet. Das Fenster landet dann hinter/unter der Taskleiste. Vermutlich wäre es ähnlich, wenn die Leiste oben oder rechts läge.
Ich hab mich aber noch nie darum gekümmert, unter welchen Umständen das genau geschieht. Mglw. hat es was damit zu tun, dass der 2. Monitor gar keine Taskleiste hat und die gespeicherte Position beim Umschalten auf wsNormal am 2. Monitor auch für den linken "Hauptmonitor" verwendet wird, wenn das Fenster dorthin geschoben wurde.
Das (Anwendungsfenster hinter Taskleiste) ist z.B. bei einer (gekauften, aber veralteten) Delphianwendung so.

[jobo]

Test unter Win10, neuer User, erstmal 5 Bilder von 22, bin mir nicht sicher, wie das hier mit der Uploadgröße ist.
Die Dateinamen enthalten jeweils ein paar Bemerkungen, das Dateinamenmuster n-100-100pct steht für n.Bild, linker Moni100Prozent, rechter Moni 100%, Dateinamen enthalten Anmerkungen.

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1398520)

Die Dateinamen enthalten jeweils ein paar Bemerkungen

Gibt es an den Darstellungen denn etwas zu bemängeln - wenn ja, was? Aus den Bemerkungen im Dateinamen werde ich nicht so ganz schlau.

[jobo]

Tja, ich glaube bis Bild Nr. 5 nicht.
Ich will/wollte mir aber da auch gar nicht die Mühe machen, das zu beurteilen.
Die Beschreibung kannst Du auch ignorieren, es ist einfach eine Folge von Bildern. Wenn ich den gleichen Aufruf einfach mehrmals gemacht habe, um zu sehen wie sich die Fensterposition ändert, kann das bspw. aus der Beschreibung hervorgehen.
Oder wenn die Anwendung maximiert wird, gibt es offenbar kein Event, der in Deiner Anwendung die dargestellte Auflösung aktualisiert. So Kram steht da drin. Ob das interessant ist oder sich alles aus dem Bild selbst erschließt .. keine Ahnung. Man weiß ja vorher nicht, was nachher interessant ist.

Und ob Daniel sich über solche Uploads freut? Falls nicht, kann ich es auch wieder löschen. Wenn Du die restlichen Bilder noch haben willst, muss dann wohl ein anderes Verfahren her.

[BlueStarHH]

Hier meine Resultate: Beide GUIs sehen fast gleich aus: Die Radiobuttions sind leicht unterschiedlich groß und die rechten und unteren Buttons im TabSheet sind weiter unten/rechts im linken Bildschirmfoto (ref)

Edit:
Gerade noch einen Unterschied gefunden: In "ref" ist das PopUp-Menü zu klein. In "Test" passt es.

4K Display unter Windows 10 mit einer Skalierung. Welche Skalierung aktiv ist, kann ich leider nicht nachschauen. Das Systemsteuerungsfenster öffnet sich seit dem Windows Update nicht mehr...

[BlueStarHH]

Hier die Bildschirmfotos von den PopUp-Menüs