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