Ausführung auf 150% Bildschirm

[Pfaffe]

Ich habe ein Notebook mit Windows 10.1, einer Bildschirmauflösung von 1920x1080 und bei der Größeneinstellung 150%.
Führe ich dort ein mir Seattle Update 1 erstelltes Programm aus, dann wird das Programm nicht richtig dargestellt (scaled=true). Egal ob ich die "Hochauflösung" eingeschaltet habe oder nicht.
Erstelle ich das Programm mit XE8, dann funktioniert es.
Ist da was Kaputt in Seattle? Welche Erfahrungen habt Ihr?

[Perlsau]

Mit Sicherheit wäre es hilfreich, wenn du "nicht richtig dargestellt" und "funktioniert es" näher erläutern bzw. definieren könntest.

[Pfaffe]

Hallo Perlsau,
bedeutet Deine Antwort, dass das Problem bei Dir ebenfalls bekannt ist?
Hier eine pdf mit Bildschirmkopien und der Quellcode vom Testprogramm, welches auch ein Problem mit dem "ParentFont" aufzeigt, welches hier erstmal keine Rolle spielen soll. Noch ein Hinweis: In der dfm setze ich die Schrift und die Schriftgröße mit Application.DefaultFont.Name:= 'Segoe UI'; und Application.DefaultFont.Size:= 9;. Diese hat auf das beschriebene Problem keinen Einfluss. Leider wird aber in der IDE die Schriftvorgabe nicht berücksicht, auch ein ParentFont = true im ersten Formular hilf nicht. Die IDE verwendet scheinbar immer die Schrift Tahoma. Wenn man ein neues Projekt erstellt ist ParentFont = false im ersten Formular.
Schaltet man nun ParentFont = true und leitet weitere Fomulare ab, dann versagt das Prinzip, sobald man bei einem Element, z.B. bei einem Label beim Text Bold wählt, dann ist nämlich sofort für dieses Element ParentFont = false und das Prinzip ist futsch.

[Perlsau]

Zitat:

Zitat von Pfaffe (Beitrag 1322812)

Hallo Perlsau, bedeutet Deine Antwort, dass das Problem bei Dir ebenfalls bekannt ist?

Nein, meine Antworten bedeuten immer das, was sie aussagen. Versteckte Bedeutungen sind zumindest in einem Fachforum kontraproduktiv, weshalb ich dich ja darauf hinwies, konkretere Angaben wie "fehlerhaft" und "funktioniert" zu machen. Mit deinen ergänzten Angaben können die User nun was anfangen.

[Harry Stahl]

Wenn Ihr in XE8 in der Manifestdatei nicht das DPIAware-Flag gesetzt habt, dann Scaled Delphi unter Windows 10 selber gar nichts (weil dem Programm eine 100%-Auflösung vorgegaukelt wird) und Windows nimmt die Skalierung selber vor.

Dadurch wird das Programm allerdings leicht verwaschen (also etwas unscharf) dargestellt.

In DX10 ist in den Optionen nun standardmaäßig das DPI-Flag gesetzt und Delphi scaled nun tatsächlich das Formular. Die Schriften sind dann auch wieder scharf.

Leider ist das ganz oft so, dass man selber noch Hand anlegen muss und Elemente z.B. in der Größe anpassen muss oder die Position justieren. Oder man verwendet die Elemente in verschiedenen Align-Kombinationen, so dass sie alle richtig ausgerichtet sind und genügend Platz haben.

Ein Programm wirklich DPI-Aware zu machen ist eine ganz schöne Arbeit, da man wirklich alle Dialoge durchgehen muss und z.B. auf 150% oder 200% Auflösung testen muss.

Davon mal abgesehen, ist in DX10 ein Bug: Auch wenn Ihr "Hochauflösung aktivieren" deaktiviert, wird diese Option nicht (dauerhaft) gespeichert. Wenn Ihr den Dialog beim nächsten Mal wieder aufruft, dann ist die Checkbox wieder aktiviert.

[Pfaffe]

Ich habe das FMX-Demo ControlsDemo.exe auf meinem "150%" Notebook ausprobiert. Das Programm wird überhaupt nicht scaliert, die Darstellung ist so klein, dass sie keinem zugemutet werden kann. Gibt es bei FMX undokumentierte Tricks dsbzgl., in der Doku von Seattle kann ich nichts finden?
Bzgl. der Eigenschaft Quality gibt es auch keine Vernünftige Hilfe.
Da ich das Alles irgendwie nicht wahrhaben will, nach meiner Meinung müsste Emba einen Rückruf für Seattle oder mind. eine Warnmeldung herausgeben, habe ic h mal eine alte Software-Suite von mir aus dem Jahr 2007 auf meinen Win 10.1 PCs installiert. In der Suite ist auch ein Visual Basic Programm dabei, alles andere sind Delphi Programme. Die Suite ließ sich ohne Probleme installieren und wird auch auf dem 150% Anzeige Geräte zufriedenstellend dargestellt. OK, die hlp-Dateien funktionieren nicht, die emf-Grafiken werden nicht mehr angezeigt, aber dafür kann man ja Tools nachinstallieren. Und diese Suite ist nicht unicode fähig.

[Harry Stahl]

Ja, unter FMX ist das mit DPI-Aware noch einmal ein anderes Thema.

Grundsätzlich ist die Voreinstellung ab Seattle so, dass die Programme DPI-Aware sind. Nur geschieht das hier im Gegensatz zur VCL bei den meisten Komponenten nicht automatisch, sondern man muss sich selber drum kümmern.

Hier gibt es zwei Wege, einen einfachen, aber mit nicht zufriedenstellenden Ergebnissen und einen aufwändigen, mit guten Ergebnissen:

1. Weg: Du legst alle Deine Komponenten in ein TLayout und sklaierst das TLayout entsprechend der DPI-Werte. Du kannst das selber mal testen: Setze im Controls-Demo bei der "ScaleTrack"Komponente den Max-Wert einmal auf "2". Wenn Du dann neu kompilierst und das Programm auf den 150 DPI-Monitor ausführst, ziehst Du die Trackbar auf 150, dann stimmt alles von der Größe her.

Leider sind hier aber seit langem Bugs drin, die immer noch nicht behoben sind: Bei einigen Komponenten treten Teile der Komponente aus dem Rahmen heraus, was nicht gut aussieht. Oder viele Komponenten zeigen feine Linien, was auf einen fehlerhaften Skalier-Algorhytmus zurückzuführen ist (vgl. Screenshot in der Anlage).

2. Weg: Du arbeitest umfangreich mit Alignments für die Komponenten und berechnest die Schriftgrößen und Größen der Elemente selber und weist die alle zur Laufzeit zu. Bei den Grafiken kommt FMX Dir entgegen, wenn Du im MultiResBitmap Grafiken mit unterschiedlichen Auflösungen hinterlegst. Da sucht das System dann automatisch das passende, je nach Auflösung raus.

Ich finde es sehr schade, dass der erste Weg nicht richtig funktioniert, für die viele Anwendungsfälle wäre das durchaus ausreichend, aber optisch ist es derzeit nicht akzeptabel.

Wie auch immer, Programme DPI-Aware zu machen, ist immer sehr viel Arbeit. Ich habe gerade meine wichtigsten VCL-Programme DPI-Aware gemacht. FMX-Programme sind Anfang des nächsten Jahres dran (derzeit sind die nicht DPI-Aware, sondern werden von Windows skaliert, eben mit dem leichten Unschärfe-Ergebnis).

[Darlo]

Zitat:

Zitat von Harry Stahl (Beitrag 1322853)

Leider sind hier aber seit langem Bugs drin, die immer noch nicht behoben sind: Bei einigen Komponenten treten Teile der Komponente aus dem Rahmen heraus, was nicht gut aussieht. Oder viele Komponenten zeigen feine Linien, was auf einen fehlerhaften Skalier-Algorhytmus zurückzuführen ist (vgl. Screenshot in der Anlage).

Genau dieses Problem mit den feinen Linien macht mich wahnsinnig. In einem Dialog tritt das Problem auf, im nächsten dann wieder nicht. Finde hier einfach keinen Ansatz, aber so kann man ja eigentlich eine Software nicht an Kunden weitergeben....

Hat jemand hier eine Idee?

[himitsu]

Ich hatte mein Notebook von 150% (Standardwert nach Erstinstallation) auf 100% umgestellt (sah sonst schlimm aus, auf einem angeschlossenen 24-Zöller)

Leider bleibt da wohl was zurück. (so wie bei den deutschen Windows, die für Delphi teilweise noch englisch sind)

Programme mit XE3 bis XE8 sehen eigentlich OK aus, aber alle alten Delphi 7-Programme und viele Java-Programme machen jetzt mist.
Bei D7 sind die Fenster zu klein und der Inhalt steht über, bzw. Rechts/Unten liegt es außerhalb des Fensters.
Bei Java ist alles komplett zu klein, also nur 75%.

Und ich fand in all den Jahren keine Lösung.

[Sherlock]

Ich verzichte auf Skalierung. Wofür kaufe ich mir mehr Pixel, wenn ich sie dann durch aufgeblasene Inhalte wieder verliere? Freilich gibt es Kunden, die mehr oder weniger Freiwillig, die Skalierung eingeschaltet haben (ab Windows 7 oder 8 wird bei angeschlossenem FullHD-Display automatisch skaliert!!). Aber die sehen den Platzverlust genau wie ich, und lassen sich gerne dazu anleiten, die Skalierung zu dekativieren.

Sherlock

[Pfaffe]

Meine Kunden entscheiden, ob sie auf 150% schalten. Sehr schön finden viele die Technik im Webbrowser Strg.-Mausrad. Die Geraration 50+ nimmt zu und die haben das Geld zum investieren.
Weiterer Erfahrungsbericht mit Test auf einem weiteren Gerät mit Win 10.1 und 150%.
Bei vcl-Programmen mit DX10 wird nicht alles skaliert, z.B. Combobox mit csOwnerDrawFixed.
Bei vcl-Programmen mit DX8 ist die Skalierung OK, jedoch die Schrift nicht super scharf.

[Sherlock]

DX8 skaliert gar nicht, das macht Windows für Dich. Darum ist es auch so unscharf. Das dürfte auch keinen Kunden freuen.

Im Prinzip wirst du nicht umhin kommen, das selbst auszuprogrammieren, auch und vor allem im Falle eines Rechners mit mehreren Monitoren (mit unterschiedlichen DPI). Dann wird Windows nämlich maximal bekloppt und selbst Microsoft Anwendungen skalieren dann nicht einheitlich richtig. Ich habe zB drei Monitore am Rechner, einer davon hat bei gleicher auflösung eine kleine Diagonale (Notebook halt) und das Outook wird immer unscharf dargestellt, Word hingegen einwandfrei. Übrigens, ich habe das Skalieren ausgeschaltet, und für alle Monitore 100% eingestellt. Warum mein 8.1 trotzdem dran rumspinnt, kann mir keiner sagen.

Sherlock

[Pfaffe]

Zitat:

Im Prinzip wirst du nicht umhin kommen, das selbst auszuprogrammieren

Das will ich nicht akzeptieren! Dafür habe ich doch bei Emba bezahlt. Ich klicke die Oberfläche zusammen und kann mich auf meine Fachwelt konzentrieren. Und mit FMX kann ich meinen Kundenkreis erweitern, da meine Programme jetzt auch unabhängig von Windows sind. Durch die Styles kann ich alte vorhandene Programme optisch aufpeppen und "Alten Wein in neuen Flaschen" verkaufen.

[bra]

Zitat:

Zitat von Sherlock (Beitrag 1323032)

Ich verzichte auf Skalierung. Wofür kaufe ich mir mehr Pixel, wenn ich sie dann durch aufgeblasene Inhalte wieder verliere? Freilich gibt es Kunden, die mehr oder weniger Freiwillig, die Skalierung eingeschaltet haben (ab Windows 7 oder 8 wird bei angeschlossenem FullHD-Display automatisch skaliert!!). Aber die sehen den Platzverlust genau wie ich, und lassen sich gerne dazu anleiten, die Skalierung zu dekativieren.

Es ist keine Lösung dem Kunden zu sagen, er soll die Skalierung abschalten. Zum einen gibt es sehschwache Leute, die ohne entsprechende Skalierung einfach gar nix mehr erkennen und zum anderen gibt es auch genügend moderne Monitore mit Auflösungen, bei denen man ohne Skalierung nicht viel erkennt.

Nur mal als Beispiel: Ich habe zuhause einen 40 Zoll Monitor mit 4k-Auflösung. Wenn ich da die Schrift auf 100% lasse, kann ich auch nur schlecht etwas lesen, also hab ich sie auf 125% gestellt.


Das Problem ist ja, dass schon die IDE selbst mit verschiedenen DPI-Skalierungen enorm rumspackt, wie soll sie es dann vernünftig mit den erstellten Programmen hinbekommen. Dazu gibt es leider Dutzende Einträge im Quality von EMB.

[Pfaffe]

Zitat:

Wenn Ihr in XE8 in der Manifestdatei nicht das DPIAware-Flag gesetzt habt, dann Scaled Delphi unter Windows 10 selber gar nichts (weil dem Programm eine 100%-Auflösung vorgegaukelt wird) und Windows nimmt die Skalierung selber vor.
...
Davon mal abgesehen, ist in DX10 ein Bug: Auch wenn Ihr "Hochauflösung aktivieren" deaktiviert, wird diese Option nicht (dauerhaft) gespeichert. Wenn Ihr den Dialog beim nächsten Mal wieder aufruft, dann ist die Checkbox wieder aktiviert.

Die Informationen von Harry Stahl haben mich ein gutes Stück weitergebracht!
Mit DPIAware-Flag in DX10 werden die Anwendungen deutlich Augen freundlicher, bei Auflösungen >100%, als wenn man die Skalierung Windows 10 überlässt. Leider, Leider, Leider, funktioniert das nicht zu 100% zuverlässig, so dass man viel testen muss, insbesondere wenn man Altprojekte mit DX10 compilieren möchte. Der Bug mit der Checkbox war mir nicht bekannt und hat meine Testerei ziemlich verfälscht. Ein Altprojekte ohne DPIAware-Flag verhält sich so, als wenn man es mit XE8 compiliert hat.
Liebe IDE Entwickler, bitte macht die Bugs raus!

[omp]

Ich bin jetzt auch über die Darstellungs-Probleme mit HDPI gestolpert.
Ribbon und Grid von DevExpress sehen sehr gut aus. Standard VCL-Komponenten sind aber viel zu groß.

Zum IDE-Bug (Checkbox ist beim Öffnen der Optionen immer aktiviert): Habe AppEnableHighDPI direkt in der .dproj auf false gesetzt. Scheint zu funktionieren.

Gruß, Harald

[omp]

Ich bin gerade wieder dabei, mich mit diesem Problem zu beschäftigen und habe auch etwas gefunden.

Kompiliert wird auf System mit 100% Skalierung (96 dpi), Hochauflösung ist in Projektoptionen aktiviert. In der dpr wird Application.DefaultFont auf Segoe UI eingestellt, Formulare haben ParentFont=true.

Auf Systemen mit 100% Skalierung (also entsprechend der Kompilierung) ist alles ok. Formulare haben DefaultFont. Auf Systemen mit abweichender Skalierung haben die Formulare wieder Tahoma.

Das Problem dürfte in TCustomForm.ReadState liegen: Dort wird Font.Size des Formulares angepasst, wenn die aktuelle Skalierung von der kompilierten abweicht. Ein Setzen von Font.Size führt dann automatisch zu ParentFont=false und somit zur Aktivierung der Font-Einstellung des Formulares mit Tahoma.

Gruß, Harald

[a.def]

Zitat:

Zitat von Pfaffe (Beitrag 1322802)

Ich habe ein Notebook mit Windows 10.1, einer Bildschirmauflösung von 1920x1080 und bei der Größeneinstellung 150%.
Führe ich dort ein mir Seattle Update 1 erstelltes Programm aus, dann wird das Programm nicht richtig dargestellt (scaled=true). Egal ob ich die "Hochauflösung" eingeschaltet habe oder nicht.
Erstelle ich das Programm mit XE8, dann funktioniert es.
Ist da was Kaputt in Seattle? Welche Erfahrungen habt Ihr?

Und schon der dritte Thread in dem gesagt wird, dass Berlin massive DPI-Probleme hat die es zuvor nicht gab.
Hoffentlich wird dieses Thema nicht runtergespielt wie die beiden anderen :(

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359617)

Und schon der dritte Thread in dem gesagt wird, dass Berlin massive DPI-Probleme hat die es zuvor nicht gab.(

Nur, daß es sich hierbei nicht um Berlin sondern Seattle gehandelt hat und es vorher dieses DPI-Flag überhaupt nicht gab (was logischerweise auch keine Fehler damit bedeutet).

So ganz kann ich das nicht nachvollziehen: Wenn man das alte Verhalten will, dann nimmt man einfach das Flag heraus. Dann sollte es sich doch wieder so verhalten wie früher, oder?

[a.def]

Das ist ja das Problem unter Delphi 10 Seattle oder Berlin.
Egal ob man es raus nimmt oder nicht, egal ob man DPIAware auf True oder False stellt, das Resultat von XE8 zu Seattle oder Berlin ist immer verschieden bei hoher DPI.
Verschieden heißt hier, dass nach XE8 alles "kaputt" dargestellt wird.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359621)

Das ist ja das Problem unter Delphi 10 Seattle oder Berlin.
Egal ob man es raus nimmt oder nicht, egal ob man DPIAware auf True oder False stellt, das Resultat von XE8 zu Seattle oder Berlin ist immer verschieden bei hoher DPI.
Verschieden heißt hier, dass nach XE8 alles "kaputt" dargestellt wird.

Ich weiß, es gibt unzählige Kombinationen von Controls und ihren Einstellungen. Ich kann deine Aussagen hier mit meiner Hauptanwendung (Berlin, kein High-DPI, Windows 10 mit 125%, habe leider keinen 4k-Monitor) nicht nachvollziehen. Es sieht halt alles etwas verwaschen aus, aber das war auch schon so als es noch mit z.B. XE7 compiliert wurde. Die Größenverhältnisse der einzelnen Controls sind zumindest optisch (ich habe nicht nachgemessen) genauso wie bei 100%.

Kannst du ein Beispielprojekt mit den nötigen Angaben zum Test anhängen, mit dem man das mal reproduzieren kann? Ich will das gerne analysieren, um herauszufinden, was man durch Einstellungen und Workarounds beseitigen kann und was als Bug am Ende noch übrig bleibt.

[Fritzew]

Also irgendwie glaube ich es nicht,
Ich habe hier ein System mit HighDpi Monitor

Schaut euch das Bild im Anhang mal an
4 mal das gleich Fenster
jeweils mit Berlin und XE7 compiliert
und das einmal mit einmal Ohne High DPI (für XE7 mit speziellem Manifest kompiliert)

Zitat:

Das Problem dürfte in TCustomForm.ReadState liegen: Dort wird Font.Size des Formulares angepasst, wenn die aktuelle Skalierung von der kompilierten abweicht. Ein Setzen von Font.Size führt dann automatisch zu ParentFont=false und somit zur Aktivierung der Font-Einstellung des Formulares mit Tahoma.

Das kann ich hier nicht nachvollziehen.

[a.def]

Von ungefähr so einem Fehler schreibe ich ja immer. Konnte es nur nicht mehr re-produzieren.

Entweder muss man sich bei Seattle/Berlin für ToolBar-Icons entscheiden die groß genug sind aber alles ist verschwommen oder aber für scharfe Schrift, Icons usw. aber die ToolBar ist dann kaputt.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359644)

Entweder muss man sich bei Seattle/Berlin für ToolBar-Icons entscheiden die groß genug sind aber alles ist verschwommen oder aber für scharfe Schrift, Icons usw. aber die ToolBar ist dann kaputt.

Die Toolbar ist nicht kaputt. Der Screenshot Berlinmit zeigt, daß die Toolbar korrekt skaliert wird, die Icons aber nicht in der passenden Größe vorliegen. Microsoft sagt ganz eindeutig, daß bei höherer DPI auch der Größe angepasste Icons verwendet werden sollen. Solange diese nicht vorliegen und auch beim DPI-Wechsel ausgetauscht werden, ist halt kein anderes Aussehen zu erwarten.

Was ich mangels Projektsourcen nicht nachvollziehen kann, ist das Verhalten im Screenshot Projectxe7mit. Dort werden offenbar z.B. die Schriften und Panels skaliert, nicht aber die Toolbars. Deswegen passt dort die Icongröße zwar zu den ToolButtons, aber das ist eigentlich nicht Sinn des High-DPI Support.

Es gibt übrigens noch eine optische Merkwürdigkeit in Berlinmit: Der erste Toolbutton scheint nicht richtig skaliert worden zu sein. Ein kurzer Test mit einem neu aufgebauten Projekt konnte diese Verhalten aber nicht reproduzieren. Hier wäre ein Einblick in die Sourcen des gezeigten Projekts sicher hilfreich.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359644)

Von ungefähr so einem Fehler schreibe ich ja immer. Konnte es nur nicht mehr re-produzieren.

Mir ist beim Testen noch eine Besonderheit aufgefallen: Das Deaktivieren von HighDPI geht nicht immer so, wie man vermutet. Ein positiver Wert (und nur der) wird, wie auch bei den anderen Manifest-Checkboxen, von der hierarchisch höheren Konfiguration geerbt. Um also die Hochauflösung wirklich zu aktivieren, muss man das top-down beginnend bei Alle Konfigurationen Win32 bzw. Win64 abschalten.

[Fritzew]

So jetzt die Projekte und Formular angehängt.
Der einzige Unterschied den ich zwischen Xe7 und Berlin sehe ist, dass die Toolbar jetzt skaliert. Das ist meiner Meinung auch richtig so

[Uwe Raabe]

Zitat:

Zitat von Fritzew (Beitrag 1359829)

So jetzt die Projekte und Formular angehängt.

Irgendwie kann ich die ZIP nicht öffnen...

[TiGü]

Zitat:

Zitat von Uwe Raabe (Beitrag 1359830)

Zitat:

Zitat von Fritzew (Beitrag 1359829)

So jetzt die Projekte und Formular angehängt.

Irgendwie kann ich die ZIP nicht öffnen...

Mit 7Zip geht's.

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1359833)

Zitat:

Zitat von Uwe Raabe (Beitrag 1359830)

Zitat:

Zitat von Fritzew (Beitrag 1359829)

So jetzt die Projekte und Formular angehängt.

Irgendwie kann ich die ZIP nicht öffnen...

Mit 7Zip geht's.

In der Tat! Allerdings gibt das bei mir auch noch eine Warnung aus: Es gibt noch Daten hinter den Hauptdaten

[Fritzew]

So habe die noch mal angehängt.....

[Uwe Raabe]

Zitat:

Zitat von Uwe Raabe (Beitrag 1359665)

Es gibt übrigens noch eine optische Merkwürdigkeit in Berlinmit: Der erste Toolbutton scheint nicht richtig skaliert worden zu sein.

So, nun hat sich das auch geklärt: die ersten beiden Buttons stehen auf AutoSize und passen sich somit der aktuellen Größe der Icons an.