Bitmaps zu klein

[juniorA]

Hallo ich bin von Delphi RAD Studio (Uralt) auf Delphi Berlin umgestiegen.
Wenn jetzt das gleiche Programm auf 2 unterschiedlichen Windows 10 Rechner läuft, ist die Darstellung auf den einen Rechen korrekt und auf den anderen werden die Bitmaps auf den Speedbuttons zu klein dargestellt. Bei der Schrift in den Formularen ist es genau umgekehrt. Bei beiden handelt es sich um Arial als Schrifttyp. Welche Einstellungen sind da nicht richtig gesetzt. Ich finde bei Speedbutton z.B. auch keine Stretch Einstellung?

[a.def]

Es ist das gleiche Programm. Aber wurde der die Exe auch mit Berlin erzeugt?
Ich hatte ähnliche Probleme, als ich meine Exe mit Berlin erstellt habe. An meinen Windows-Einstellungen lag es nicht. Bei meinem älteren XE8 gibt es das Problem nicht. Nur bei Berlin.

[himitsu]

Es sieht einfach so aus, dass die Bitmaps Pixelmäßig gleich groß bleiben
und ihr euch vorstellt, dass sie auf einem High-DPI-System größer dargestellt werden sollten,
genauso wie die Buttons und die Schrift größer werden.

Nur werden die Buttons/Fonts eben mit mehr Pixeln dargestellt und die Bilder müssten gestretcht werden, oder man verwendet Icons mit mehr Pixeln.

[a.def]

Ich glaube nicht, dass das nur so aussieht. Eine Messung hat bei mir ergeben, dass die Icons tatsächlich kleiner sind bei höherer DPI.
Es sind ja nicht nur die Bitmaps. Eine meiner Anwendungen sah mit Berlin kompiliert komplett anders aus als mit XE8. Da muss doch irgendwas dran sein.

Siehe: https://forums.embarcadero.com/messa...ssageID=826170

[himitsu]

Messung: In Millimeter oder in Pixeln?
Gut, auf den Zweiten längeren Blick sind die Oberen verschwommen und nicht so schön pixelig, wie die Unteren.

Allerdings ist auch die Caption verschwommen und das MainIcon schiebt sich über die Schrift ... dachte daher, daß das HD-Bild für den Vergleich maßstabsgetreu verkleinert wurde.

[a.def]

Zitat:

Zitat von himitsu (Beitrag 1358999)

Messung: In Millimeter oder in Pixeln?

Ich habe mit einem Lineal direkt am Bildschirm gemessen. In Berlin sind SpeedButtons (ToolButtons übrigens auch) größer und die Icons sind kleiner.
Vor Berlin war das nie der Fall.

Ich installiere mir gleich mal Berlin Starter in eine VM und erstelle eine kleine Demo welche ich dann mit XE8 und Berlin kompiliere.
Danach mache ich Screenshots. Kann aber etwas dauern.

[Fritzew]

Schalte mal in den Projektoptionen Anwendung
die Hochauflösung aus und dann vergleiche das noch mal

[himitsu]

Dann sollte es so wie im NichtHD-Windows aussehn ... nur pixelliger.

Wenn man Windows im Manifest nicht sagt, dass seine Anwendung HD kann, dann tut Windows so, dass es ein NichtHD-Bildschirm ist, lässt die Anwendungen in der kleineren Auflösung laufen und zoomt das Fenster dann nur in der Anzeige größer.

Wenn man das aktiviert hat, dann macht Windows nichts, und das Programm läuft in der nativen Auflösung, also erstmal alles zu klein.
Hier muß sich dann die VCL/FMX selber um das Zoomen kümmern, wobei es hier nicht so pixellig ist, da dabei halt die Komponenten größer und mit mehr Pixeln gezeichnet werden.
Und hierbei scheint Delphi/Windows sich bei den Button-Bitmaps bissl zu vertun.

[Fritzew]

mir ist das schon klar,
nur sollte es dann eigentlich genau wie unter XE8 aussehen.
Die ganze High DPI Geschichte ist weder von der VCL noch von Windows wirklich sauber gelöst.

Ganz interessant in diesem Zusammenhang:

https://blogs.windows.com/buildingap...ersary-update/

[himitsu]

Zitat:

Zitat von Fritzew (Beitrag 1359069)

Die ganze High DPI Geschichte ist weder von der VCL noch von Windows wirklich sauber gelöst.

Das aktuelle Delphi behauptet aber von sich, dass es das nun kann. :stupid:

[Fritzew]

Zitat:

Zitat von himitsu (Beitrag 1359071)

Zitat:

Zitat von Fritzew (Beitrag 1359069)

Die ganze High DPI Geschichte ist weder von der VCL noch von Windows wirklich sauber gelöst.

Das aktuelle Delphi behauptet aber von sich, dass es das nun kann. :stupid:

Ja leider.......
angehängt mal ein Screenshot gleiches Programm einmal mit einmal Ohne HighDpi

[Uwe Raabe]

Es ist leider so, daß man für die Skalierung der Icons selbst sorgen muss. Selbst wenn Delphi das übernehmen würde, sähe es nicht besser aus als das Windows-Ergebnis.

Nun hat man mit FMX ja schon eine komplexere Imagelist geschaffen, die auf solche Skalierungen reagieren könnte (nicht, daß man dadurch von der Bereitstellungen der verschiedenen Größen befreit wäre, wenn man ein sauberes Ergebnis möchte). Leider lässt sich diese Technik nicht so einfach in die VCL übernehmen, da man hier noch an die Windows-interne ImageList-Implementierung gebunden ist.

Es bleibt also bis auf Weiteres in der Hand des Entwicklers, bei unterschiedlichen Bildschirmskalierungen die passenden Bildchen bereitzustellen.

[Fritzew]

Zitat:

Es bleibt also bis auf Weiteres in der Hand des Entwicklers, bei unterschiedlichen Bildschirmskalierungen die passenden Bildchen bereitzustellen.

Nur ist es leider nicht nur die Imagelist die Probleme macht.
Wir haben hier eine relativ Grosse Anwendung auf DPI Aware umgestellt. Wir "mussten"
da wir im CAD Bereich zu Hause sind und bei unseren Kunden schon sehr viele solcher Displays stehen.
Leider auch im "mixed mode", also verschiedene DPI auf den Monitoren. Wenn ich für jeden Fluch den ich bei dieser Umstellung gehört habe, 5€ bekäme würde ich sofort in Rente gehen :-) Da ist an vielen Stellen in der VCL noch manches im argen. Ich will es aber gar nicht unbedingt auf EMBA schieben. Microsoft hat da seinen "Job" auch eher schlecht als recht gemacht.
Aber wenn EMBA jedem der noch verbliebenen Entwickler eine HIGH DPI Monitor hinstellen würde... (könnte helfen)

Es ist auf jeden Fall ein nicht zu unterschätzender Zeitaufwand.
Und jeder Entwickler der seinem Programm das DPI enabled Flag im Manifest mitgibt und es dann nicht kann, müsste mit reiner C Programmierung nicht unter 3 Jahren bestraft werden!!!!

[Uwe Raabe]

Zitat:

Zitat von Fritzew (Beitrag 1359079)

Und jeder Entwickler der seinem Programm das DPI enabled Flag im Manifest mitgibt und es dann nicht kann, müsste mit reiner C Programmierung nicht unter 3 Jahren bestraft werden!!!!

:lol:

[a.def]

Zitat:

Zitat von himitsu (Beitrag 1359071)

Zitat:

Zitat von Fritzew (Beitrag 1359069)

Die ganze High DPI Geschichte ist weder von der VCL noch von Windows wirklich sauber gelöst.

Das aktuelle Delphi behauptet aber von sich, dass es das nun kann. :stupid:

Dann haben die aber irgendetwas kaputt gemacht, um ein entsprechendes Resultat zu bekommen. Denn vor Berlin war in High-DPI alles ok :P

[Fritzew]

Zitat:

Dann haben die aber irgendetwas kaputt gemacht, um ein entsprechendes Resultat zu bekommen. Denn vor Berlin war in High-DPI alles ok

Was für ein Manifest hast Du denn mit XE8 eingebunden? Ich denke da bist Du auf dem Holzweg.
Das was Du siehst ist der unterschied dpi-aware oder nicht

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359107)

Dann haben die aber irgendetwas kaputt gemacht, um ein entsprechendes Resultat zu bekommen. Denn vor Berlin war in High-DPI alles ok :P

Das stimmt nur insoweit wie man die automatische Windows-Skalierung als ok betrachtet. Die kann man aber ohne High-DPI-Option auch in Berlin haben.

[a.def]

Zitat:

Zitat von Fritzew (Beitrag 1359109)

Zitat:

Dann haben die aber irgendetwas kaputt gemacht, um ein entsprechendes Resultat zu bekommen. Denn vor Berlin war in High-DPI alles ok

Was für ein Manifest hast Du denn mit XE8 eingebunden? Ich denke da bist Du auf dem Holzweg.
Das was Du siehst ist der unterschied dpi-aware oder nicht

Es war ein und derselbe Code ohne irgendeine Änderung einmal kompiliert mit XE8 und dann mit Berlin.

[Fritzew]

Zitat:

Es war ein und derselbe Code ohne irgendeine Änderung einmal kompiliert mit XE8 und dann mit Berlin.

Und höchtwahrscheinlich die highdpi einstellungen in den projektoptionen gesetzt!!
Das wäre dann die Erklärung

[a.def]

Zitat:

Zitat von Fritzew (Beitrag 1359112)

Zitat:

Es war ein und derselbe Code ohne irgendeine Änderung einmal kompiliert mit XE8 und dann mit Berlin.

Und höchtwahrscheinlich die highdpi einstellungen in den projektoptionen gesetzt!!
Das wäre dann die Erklärung

Nein. War deaktiviert und aktiviert. Habe beides getestet. Dazu gab es hier auch mal einen Thread von mir.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1359113)

Nein. War deaktiviert und aktiviert. Habe beides getestet. Dazu gab es hier auch mal einen Thread von mir.

Wobei dort auch die Auswirkungen des von dir verwendeten

Delphi-Quellcode:

Scaled = false

nicht näher analysiert wurden. Mit dieser Einstellung setzt du immerhin den Automatismus außer Kraft und bist selbst für die korrekte Skalierung verantwortlich. Da sich mit Berlin so Einiges in diesem Bereich getan hat und

Delphi-Quellcode:

Scaled = false

eher selten angewendet wird, kann es natürlich sein, daß diese Kombination bei der Implementierung nicht ausreichend bedacht wurde und dort noch ein paar Fehler schlummern.

[Fritzew]

So ich habe das jetzt mal durchgespielt mit XE7 und Berlin (habe hier kein XE8 installiert)
im Anhang 2 Bilder
Jeweils compiliert

• ohne Manifest für HighDpi,
• mit Manifest für HighDpi,
• mit Manifest für HighDpi und Scaled der Form false,

Leider als Zip da die Anhänge hier sonst zu gross werden

[Uwe Raabe]

Hier sieht man, daß bei Berlin mit aktivem High-DPI die Buttons ebenfalls vergrößert werden, allerdings mit den vorhandenen, zu kleinen Icons. Bei XE7 behalten die Buttons ihre Größe, wie auch bei Scaled = false.

Würde man jetzt unter Berlin die Icons an den aktuellen DPI-Wert anpassen (z.B. in dem man die ImageList dynamisch durch eine mit größeren Bildchen ersetzt), wäre das Ergebnis ähnlich dem ohne High-DPI-Unterstützung, nur besser.

Danke! Die Screenshots unterstreichen meine vorige Aussage.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1359117)

Wobei dort auch die Auswirkungen des von dir verwendeten

Delphi-Quellcode:

Scaled = false

nicht näher analysiert wurden. Mit dieser Einstellung setzt du immerhin den Automatismus außer Kraft und bist selbst für die korrekte Skalierung verantwortlich. Da sich mit Berlin so Einiges in diesem Bereich getan hat und

Delphi-Quellcode:

Scaled = false

eher selten angewendet wird, kann es natürlich sein, daß diese Kombination bei der Implementierung nicht ausreichend bedacht wurde und dort noch ein paar Fehler schlummern.

Da formulierst Du aber sehr zurückhaltend. Wenn man bedenkt, daß schon D7 nicht ordentlich skalieren konnte, hat sich da wohl in den letzten Monaten nicht viel getan. Und dem Benutzer ist es ..egal warum sein Programm so seltsam aussieht, "da war wohl jemand nicht ganz qualifiziert für seinen Job".

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1359143)

schon D7 nicht ordentlich skalieren konnte, hat sich da wohl in den letzten Monaten nicht viel getan.

Das würde ich aber schon sagen. Die Screenshots von Fritzew zeigen ganz deutlich, daß sich das Verhalten geändert hat. Man darf nur nicht erwarten, daß automagisch aus 16x16 Bitmaps plötzlich 24x24 oder 48x48 Bitmaps mit mehr Details werden. Dafür muss der Entwickler schon selber sorgen. Das geht auch aus den einschlägigen Tutorials von Microsoft hervor.

Zitat:

Zitat von p80286 (Beitrag 1359143)

Und dem Benutzer ist es ..egal warum sein Programm so seltsam aussieht, "da war wohl jemand nicht ganz qualifiziert für seinen Job".

Das ist allerdings richtig - und unterstreicht nochmal die Notwendigkeit einer Diskussion wie dieser.

[Fritzew]

Zitat:

Das ist allerdings richtig - und unterstreicht nochmal die Notwendigkeit einer Diskussion wie dieser.

Ja das stimmt wohl alles. Ich will mich hier noch einmal wiederholen. Es ist ein Aufwand und benötigt Zeit und ein vernünftiges Konzept.
Gerade in Multi DPI Settings sprich mehrere Monitore mit unterschiedlichen DPI Auflösungen ist es nicht einfach das sauber hinzubekommen.
Wir haben das bei uns gelöst in dem wir alle!!! Formulare von einer Basis-Klasse ableiten die je nach dem verschiedene Events auslöst.
All das muss recht aufwändig getestet werden. Wer erwartet das es einfach mit setzen einer checkbox getan ist, wird Probleme bekommen.
Das muss man aber auch den Kunden oder dem Management klar machen, es kostet!
Wenn man sieht wie schwer sich selbst Microsoft damit anstellt kann man erkennen das es nicht trivial ist.
Und wenn ich sehe wie viele Anwendungen behaupten DPI Aware zu sein und es nicht sind....... :evil:

[a.def]

Zitat:

Zitat von Fritzew (Beitrag 1359147)

Zitat:

Das ist allerdings richtig - und unterstreicht nochmal die Notwendigkeit einer Diskussion wie dieser.

Ja das stimmt wohl alles. Ich will mich hier noch einmal wiederholen. Es ist ein Aufwand und benötigt Zeit und ein vernünftiges Konzept.
Gerade in Multi DPI Settings sprich mehrere Monitore mit unterschiedlichen DPI Auflösungen ist es nicht einfach das sauber hinzubekommen.
Wir haben das bei uns gelöst in dem wir alle!!! Formulare von einer Basis-Klasse ableiten die je nach dem verschiedene Events auslöst.
All das muss recht aufwändig getestet werden. Wer erwartet das es einfach mit setzen einer checkbox getan ist, wird Probleme bekommen.
Das muss man aber auch den Kunden oder dem Management klar machen, es kostet!
Wenn man sieht wie schwer sich selbst Microsoft damit anstellt kann man erkennen das es nicht trivial ist.
Und wenn ich sehe wie viele Anwendungen behaupten DPI Aware zu sein und es nicht sind....... :evil:

Ähnlich bei mir.
Ich prüfe beim Erzeugen eines Formulars, ob die DPI ungleich der ist, die ich zur Entwicklung benutzt habe.
Ist das der Fall, treffe ich einige Änderungen selber von Hand (vorher sehr aufwändig getestet mit allen möglichen DPI unter XP über Win 7 bis Win10).
Aufwändiges Testen und selber "reparieren" scheint mir die einzige brauchbare Lösung, wenn man dem Benutzer eine ordentliche Benutzeroberfläche bieten möchte.