DPI? PPI? High-DPI? Was jetzt?

[Nimral]

Ich habe jetzt angemessen Zeit (etwa 2 Stunden) verblasen bei dem Versuch, durch Lesen von Webseiten (darunter auch der Lazarus Wiki D und E) herauszubekommen, wie genau dieses an sich triviale Thema unter Lazarus aufgefasst werden muss, damit man keine unerwünschten Clipping- und Verschiebeeffekte bei Bildern und Glyphen bekommt.

Ich schaffs nicht. Die Texte ergeben (nicht nur für mich, das zeigen die Nachfragen in diversen Foren) kaum einen Sinn, sind also im besten Fall nicht hilfreich.

Ich versuchs also mit einem Beispiel:

Verschobene Bilder zwischen Design- und Runtime.png (20.87 KiB) 2511 mal betrachtet

Oben ein Speedbutton mit Glyph, unten ein Multibutton.

Bei meiner Anlage kommt erschwerend dazu, dass der eine Schirm (Laptop) mit 141 PPI arbeitet, der Großschirm mit 91 PPI. Windows 10 erachtet deswegen für den Laptop-Schirm ein Scaling von 125% für optimal (ich rate: eigentlich wären es ja 150%, dann wäe eine Linie aus x Pixeln auf beiden Schirmen etwa gleich lang, das wäre aber praxisfremd, weil man den LaptopSchirm mit weniger Abstand anschaut, Symbole dürfen also ruhig kleiner sein, also investiert man die Hälfte der zusätzlichen Pixel in eine Vergrößerung der sonst arg kleinen Symbole, and die andere Hälfte sorgt für verbesserte Bildschärfe). Beim "Großen" belässt es Windows bei 100%, und da 91PPI (Panel) und 96 DPI (Standard-Annahme) nicht weit auseiandnder liegen passt das so.

Der DesignTimePPI bezeichntete Parameter im TForm steht auf 120 und lässt sich von Hand nicht ändern.

Wer kann - bitte Schritt für Schritt - erläutern, wie dieses gnze dubiose Zeugs zusammengedengelt werden muss, damit meine Formulare funktionieren?

Ich vermute, das Ziel wäre erreicht, wenn folgende Dinge eintreten:

- Annahme: auf dem 91 PPI Monitor wird das Formular gezeichnet

Die EInstellung beider Monitore auf 100%:

- auf dem 140 PPI Monitor ist es noch etwa halb so groß, aber alle Proportionen stimmen

Jetzt stelle ich den Laptop-Schirm auf 120%, Resultat:

- auf dem Laptop-Schirm stimmen die Proportionen, aber die Glyphen werden etwas unscharf/gezackt, da die Bilder hochskaliert werden müssen --> da kann ich dann in Schritt 2 mit einer ImageList dagegen halten. wp hat da einen sehr brauchbaren Beitrag geschrieben, wie man die Image-Listen aufbauen muss, das wirklich Schwierige ist dabei die Bedienung der Imagelist GUI, da sie die entscheidenden Begriffe "Auflösung" und "Größe" ziemlich willkürlich durcheinander schmeißt, und keine brauchbare Doku zu dem Control existiert.

Thnx, Armin.

[wp_xyz]

Was ist ein "MultiButton"?

[Nimral]

Multibutton: viewtopic.php?f=29&t=13252&start=30

Ich habe das Control in meinem aktuellen Projekt eingesetzt und bin sehr gut damit gefahren, auch weil Bernd geniale Background - Infos liefert. Ich vermute, dass das Darstellungsproblem "irgendwie" mit High-DPI zusammenhängt, und da ich dieses Thema bisher nur in Ansätzen verstanden habe bitte ich mal wieder das Forum um Erklärungen, bis ich es verstanden habe.

Armin,

[wp_xyz]

Fremdkomponenten müssen natürlich so geschrieben sein, dass sie sich entsprechend der aktuellen Pixeldichte anpassen können. Insbesondere dürfen keine konstanten Längenangaben im Code vorhanden sein - wie sollte das Scaling denn sonst da etwas umrechnen können? Es gibt eine Methode, DoAutoAdjustLayout, die aufgerufen wird, wenn sich die DPI ändern, und darauf muss die Komponente reagieren (https://wiki.lazarus.freepascal.org/Hig ... 8_and_abov: "If some of your components..."). Außerdem gibt es noch zwei Methoden für die Fonts. Am besten in der LCL nachsehen.

(Aber eigentlich gehört diese Antwort in den anderen Thread...)

[Nimral]

Ich war mir nicht sicher.

Überhaupt komme ich mit diesem ganzen Thema "Dots" vs "Pixel" vs "Imagelist" vs "High-DPI" vs "Windows-Skalierung" vs "DesignTimePPI" vs Projekt-Settings (Themes) nicht zurecht, und das ist blöd, weil genau meine Entwicklungsanlage (32 Zöller mit ~2500x1400 und 15,6" Laptop-Schirm mit 1980x1024 - Windows 10 stellt per Default 100% und 125% scaling ein) darunter fällt, und meine andere Anlage (2 mal 2500x1400/100% scaling) gerade nicht. Mir fallen ständig die Formulare auseinander, und so habe ich erst mal ein Problem aus der Ecke vermutet, aber Du hast Recht, es könnte natürlich auch ein Bug in dieser Komponente sein.

Ich schwimme da so grundlegend dass ich nicht einmal genau weiß, wonach ich fragen könnte, weil die Einführung im Wiki meiner Meinung nach ebenso widersprüchlich wie ungenau ist.

Kannst Du da irgendwie weiter helfen?

Armin.

[wennerer]

Hallo Armin,
da ich fast ausschließlich unter Linux teste. Habe ich mich mit dem Thema noch nicht befasst. Wp hat natürlich vollkommen recht, wenn das richtig gehen soll muss es implementiert sein. Jedenfalls habe ich mein Win10 mal gestartet und von 100% bis 150% umgestellt. Folgendes habe ich beobachtet:
Stelle ich die Anzeige z.B. auf 125% und kompiliere das Multibutton Package neu passt die Anzeige für 125%. Da müsstest du natürlich wissen welche Auflösung verwendet wird und es darf keiner umstellen. Ist blöd.
Ich habe dann bei der Form scaled auf false gesetzt. Im ersten Eindruck hat dann alles gut ausgesehen. Kannst du ja mal testen.

Scaled.png (41.08 KiB) 2469 mal betrachtet

Viele Grüße
Bernd

[wp_xyz]

Experimentiere mit kleinen Programmen und mache kleine Schritte. Zunächst: auf allen Systemen muss in den Optionen des Formulareditors das Häkchen bei "Force DPI scaling at design time" gesetzt sein (ist so standardmäßig), und wenn du ein neues GUI-Projekt erzeugt müssen in den Projekt-Optionen LCL-Scaling und bei Windows "DPI awareness" auf "on" gesetzt sein.

Gehe zu einem System mit 96ppi (100%). Setze ein paar Controls auf ein Formular. Kompiliere und starte das Programm, mache einen Screenshot. Übertrage das Programm (Code + Exe) auf das andere System mit 125%. Starte die Exe, die mit 100% erzeugt wurde. Mache einen Screenshot. Es muss nun alles um 25% größer sein als bei ersten Screenshot. Lade das Programm in den Lazarus auf dem 125%-System - wieder: alle Längen müssen um (ca) 25% größer ausfallen als bei dem anderen System. Auch nach dem Übersetzen.

Kannst du das bis hierher nachvollziehen?

Das alles ohne Bilder, die sind ein eigenes Kapitel.

[Nimral]

@Bernd: das probiere ich gerne, und sag dann Bescheid.

Das Problem hat zwei Ebenen:

- wie bekomme ich irgendeine Lösung für das aktuelle Projekt? "Scaled" = false schaut da vielversprechend aus
- wie hätte das Ganze denn funktionieren sollen? Ich meine, die Basics sind mir ziemlich klar, da gibt es eben High-DPI Schirme, und man will nicht, dass alles kleiner wird, man will die zusätzlichen Pixel in Schärfe umgesetzt. Mit ähnlichen Aufösungen gibt es aber auch große Desktop-Schirme, da will man dass die Pixels in zusätzliche Arbeitsfläche umgesetzt werden, Schärfe ist auch kein Thema weil der Betrachtungsabstand idR größer ist.

Daher die Windows-Einstellung - nur, wie funktioniert das Ganze jetzt eigentlich zusammen? Was genau muss ich als Entwickler beachten, damit Formulare sowohl bei mir während der Designe-Time als auch auf verscheidenen Anlagen bei Kunden vernünftig laufen? Und wie spielt die WIndows-Einstellung da mit rein?

@WP: Danke, die Messages haben sich überschnitten ... ich mach mich gleich an die Arbeit. Vielleicht lassen sich die Screenshots dann isn Wiki einarbeiten.

Armin.

[wp_xyz]

Stelle ich die Anzeige z.B. auf 125% und kompiliere das Multibutton Package neu passt die Anzeige für 125%. Da müsstest du natürlich wissen welche Auflösung verwendet wird und es darf keiner umstellen. Ist blöd.
Ich habe dann bei der Form scaled auf false gesetzt. Im ersten Eindruck hat dann alles gut ausgesehen. Kannst du ja mal testen.
Scaled.png

Wenn es richtig gemacht ist, spielt die Auflösung des Anwenders keine Rolle. Und Scaled=False ist keine Lösung für Leute, sich eine Super-Retina-Monitor mit 300ppi gekauft haben und sich dann wundern, warum der Entwickler dieser Software so winzige Formulare verwendet.

Wenn ich in deinen Code gucke, sehe ich schon schon im TMultiButton.Create konstante Längenangaben, die natürlich nicht mitskalieren, das heißt, ein Rand, der bei 100% passend aussieht, wird bei 300% zu einem "Rändchen", weil ja die Außenmaße der Komponente vom LCLScaling vergrößert werden. Man könnte jetzt hier schon immer die Skalierungsfunktionen aufrufen (z.B. Scale96ToForm, was davon ausgeht, dass die als Parameter angegebene Zahl für 96ppi gilt), aber damit umgeht man diverse Optionen des LCLScaling. "Richtig" ist es - und so hat es Ondrej (der Erfinder des LCLScaling) auch in der LCL gemacht - die zentrale Skalierungsfunktion zu überschreiben, die immer dann aufgerufen wird, wenn sich die Pixels-Per-Inch ändern, z.B. weil ein bei 96ppi designtes Formular auf einem 192ppi-Monitor geöffnet wird, oder weil ein Formular zur Laufzeit auf einen Zweitmonitor mit anderer Auflösung gezogen wird. Das ist die virtuelle Methode DoAutoAdjustLayout. In deinem Fall wäre der Aufruf etwa so

Code: Alles auswählen

procedure TMultiButton.DoAutoAdjustLayout(const AMode: TLayoutAdjustmentPolicy;
      const AXProportion, AYProportion: Double);
begin
  inherited;
  if AMode in [lapAutoAdjustWithoutHorizontalScrolling, lapAutoAdjustForDPI] then begin
    FMessageButton.FWidth := round (FMessageButton.FWidth * AXProportion);
    FMessageButton.FHeight := round (FMessageButton.FHeight * AYProportion);
    FMessageButton.FRRadius := round(FMessageButton.FRRadius *AXProportion);
    ... (usw).
  end;
end; 

Ich hoffe jetzt, dass das richtig ist, denn ich muss mich da auch jedesmal wieder reindenken. Ein Problem ist, wenn man's falsch macht, dass die Skalierung mehrfach angewendet wird, und dann wird alles zu groß. Aber ich möchte jetzt nicht in die Tiefen deiner Komponente eintauchen und alles ausprobieren.

Aber im Prinzip ist das der Trick. Schau dir die Beispiele in der LCL an, da wird das mehrfach angewendet - bei jeder Komponente die DoAutoAdjustLayout überschreibt.

[wp_xyz]

Ich meine, die Basics sind mir ziemlich klar, da gibt es eben High-DPI Schirme, und man will nicht, dass alles kleiner wird, man will die zusätzlichen Pixel in Schärfe umgesetzt. Mit ähnlichen Aufösungen gibt es aber auch große Desktop-Schirme, da will man dass die Pixels in zusätzliche Arbeitsfläche umgesetzt werden, Schärfe ist auch kein Thema weil der Betrachtungsabstand idR größer ist.

Diese Gedanken spielen nur für den Enduser ein Rolle. Er sucht ein für seine Zwecke passendes System und stellt die Auflösung entsprechend ein, so dass er mit allen Programmen optimal arbeiten kann. Dein Programm darf nur nicht aus der Reihe scheren (und mit Scaled=false macht es das).

Daher die Windows-Einstellung - nur, wie funktioniert das Ganze jetzt eigentlich zusammen? Was genau muss ich als Entwickler beachten, damit Formulare sowohl bei mir während der Designe-Time als auch auf verscheidenen Anlagen bei Kunden vernünftig laufen? Und wie spielt die WIndows-Einstellung da mit rein?

Eigentlich läuft das alles automatisch, du musst als Anwendungsentwickler nicht speziell darauf achten (als Komponenten-Entwickler (--> wennerer) dagegen sehr wohl, denn er muss dafür sorgen, dass alle inneren Größe entsprechend der DPI skaliert werden). Natürlich gibt es immer noch ein paar Stellen, wo es hakt, z.B. bei den Glyphs des BitBtn und SpeedButton.

[Nimral]

Natürlich gibt es immer noch ein paar Stellen, wo es hakt, z.B. bei den Glyphs des BitBtn und SpeedButton.

... und dafür ist dann die ImageList die richtige Medizin?

Und um parallel auch ein wenig drüber nachzudenken, wie man das Wiki schreiben müsste, damit ich es ohne Weiteres kapiert hätte ...

DPI (Dots Per Inch) is the relation between size in pixels and the actual display size.

Dieser meiner Meinung nach völlig falsche Satz findet sich in allen Lazarus Wikis, die sich um das Thema High-DPI und scaling drehen. Es gibt tatsächlich ein Verhältnis (eine Verhältniszahl) zwischen den DPI (nach Lazarus/Windows Defintion, das gehört schon mal erklärt, denn einstmals war m.W. DPI und PPI (in Bezug auf eine GUI) das Selbe), aber das ist irreführend, sie sind keine "Relation".

Armin.

[wp_xyz]

Ja, die kann nun verschiedene Bildgrößen verarbeiten, und wenn TImageList.Scaled auf true steht, wird die zur aktuellen Auflösung passende Größe genommen. ABER: Die mehrfachen Bitmaps, die sich je nach Zustand ändern, werden m.W. nicht unterstützt; das ist also wie NumGlyphs = 1.

[wennerer]

Hallo,
wie ja schon gesagt bin ich eigentlich nur in Linux unterwegs und da habe ich noch keine Bildschirmskalierung gefunden. Ist aber ein spannendes Thema. Ich habe mal etwas mit den Tipps von wp_xyz herum getestet (die wie immer den Nagel auf den Kopf treffen) und konnte zumindest die Position des Images und der Caption auf die schnelle anpassen. Die Schriftgröße habe ich einfach mit den x Faktor multipliziert. Das geht ja aber wohl noch besser. Ich denke mal auf die schnelle lässt sich das sicherlich nicht ordentlich nachrüsten, das braucht Zeit. Ich stelle meinen kleinen Test mal in den anderen Beitrag ich denke da passt er besser hin. Damit das Image noch besser aussieht muss man denke ich noch etwas mit der Imagelist herumprobieren. Eventuell bringt es was wenn man ein etwas größeres Image nimmt und es wird herunter skaliert. Ich habe zwar mehrere Größen in der Imagelist hinterlegt mir ist aber nicht klar ob da wirklich das beste genommen wird. So sieht es aus, links 100%, rechts 150%(der Oberste ist ein SpeedButton):

[wp_xyz]

Die ImageList von Laz2.0+ kann mehrere Bildgrößen bearbeiten. Die unterstützten Größen gibt man im Bildlisten-Editor mit dem Button "Neue Größe/Auflösung" an. Mit der Scaled-Property schaltet die ImageList dann je nach Bildschirmauflösung zwischen die so definierten Bildgrößen um. Wenn du z.B. für ein Menü eine Standardbildgröße von 16x16 verwenden willst, lässt du ImageList.Width und .Height bei 16, und bereitest die ImageList z.B. für 24x24 und 32x32 vor. Das bedeutet, dass die 16x16-Bilder genommen werden, wenn die Anwendung unter 100% (96ppi) läuft, die 24x24 unter 150% (144ppi) und die 32x32 unter 200% (bei Zwischenwerten wird die nächst kleinere Größe genommen, also die 16x16 bei 125%, es sei denn man definiert sich auch noch eine vierte Auflösung dafür; allerdings wächst mit jeder Bildgröße der Speicherbedarf).

Man kann im Bildlisten-Editor Bilder in jeder Größe einsetzen, sie werden auf die definierten Zielgrößen skaliert. Da beim Hochskalieren meist eine drastische Qualitätseinbuße erfolgt, ist es ratsam zumindest die größte Bildgröße einzutragen, wenn man schon nicht für jede Größe ein optimiertes Bild hat.

Wenn man eine ImageList in einer Komponente verwendet, kann man nicht mehr von der in ImageList.Width und .Height vorgegebenen Bildgröße ausgehen, die gilt nur für 96ppi. Und genauso muss man bei der Ausgabe der gespeicherten Bilder aufpassen, dass man die richtige Bildgröße verwendet. In den LCL-Controls findet man dazu mehrere Methoden. Die folgende wird sinngemäß im TToolbutton.Paint verwendet:

Code: Alles auswählen

var
  iconSize: TSize;
...
  if (FImageList <> nil) then
  begin
     iconSize := FImageList.SizeForPPI[FImagesWidth,  Font.PixelsPerInch];
     ....
     FImageList.ResolutionForPPI[FImagesWidth, Font.PixelsPerInch, GetCanvasScaleFactor].Draw(Canvas, IconPos.X, IconPos.Y, FImageIndex);

Dabei ist FImageList die ImageList, die der Komponente zugeordnet ist. FImagesWidth ist die Bildgröße, die für 96ppi verwendet wird; das ist neben ImageList auch als Property realisiert; der Default-Wert 0 meint: nimmt die in ImageList.Width und .Height voreingestellten Werte (das ist ein nettes Feature, denn man kann so ein und dieselbe Imagelist für große und kleine Icons verwenden, wie bei TListView). Font.PixelsPerInch bestimmt die aktuell geltenden Pixels-per-Inch. GetCanvasScaleFactor berücksichtigt einen übergeordneten Skalierungsfaktor (wie bei macOS wo sich die 100% nicht auf 96, sondern auf 72ppi beziehen).

[Nimral]

Also wie befürchtet, ich komme mit der ImageList auf keinen grünen Zweig. TImageList ist ein bedienungstechnischer Albtraum.

Ich wolte folgenden Test aufbauen:

- ich mach mir ein 16x16 Icon, packe es auf einen Speedbutton, mache dann 20, 24 und 32 Punkt Versionen davon (anders gefärbt damit ich sie gut unterscheiden kann in der Testapplikation), lasse das Programm laufen, und schalte die Windows Skalierungen 100% - 200% durch, und erwarte als Ergebnis dass der Speedbutton größer wird und das Icon auch, auf Grund der Einfärbung sehe ich auch, welches der vier Bilder als Basis für die skalierte Version hergenommen wurde.

Allzu weit komme ich nicht.

- Speedbutton und 16x16 Image gezeichnet auf einem 96 PPI Monitor bei Windows Skalierung 100% ( was m.E. aber eigentlich keine Rolle spielt)
- Weitere Images mit 20x20 (125%), 24x24 (150%) und 32 (200%) vorbereitet, damit ich den Unterschied gut sehen kann in verschiedenen Farben
- ImageList hinzugefügt, scaled auf true, width und height auf 16 und mit dem Speedbutton verbunden
- Imagelist geöffnet und erst mal die Größen 16, 20, 24 und 32 hinzugefügt. Es beginnt zu hakeln: es gibt keinerlei visuelles Feedback zu den hinzugefügten Größen. Hat dann wohl nicht geklappt.
- "Mehrere Größen hinzufügen", die 4 vorbereiteten Bilder markiert, öffnen --> es erscheint nur ein Bild (das 16x16). Das Hinzufügen der Größen war also auch hier nicht erfolgreich

Images.png (35.03 KiB) 2344 mal betrachtet

Imagelist.png (27.77 KiB) 2344 mal betrachtet

Ab hier stecke ich fest und bekomme keine Möglichkeit mehr, um die anderen Bilder hinzuzufügen. Irgendwann beim Rumprobieren komme ich auf den Trichter, die (bereits einmal hinzugefügte) Größe 20 nochmal hinzuzufügen, und jetzt gibt es Bewegung, ich erhalte eine vergrößerte Version meines 16x16 Icons. Hurra, er hat die neue Größe geschnallt, zumindest die linke Seite des (auch sonst ziemlich schizophrenen) Dialogs, man muss also mindestens ein Bild in der Liste haben bevor man zusätzliche Größen hinzufügen kann? Aber da sollte eigentlich das 20x20 Image drauf, keine hochskalierte Version meines 16x16, aber ich kann nirgends etwas zuweisen, sowohl "Hinzufügen" als auch "Mehrere Größen hinzufügen" eröffnen ein neues Bild.

Mehrere Images.png (7.22 KiB) 2344 mal betrachtet

Wie komme ich hier weiter?

HG, Armin.