LCL Scaling

[kupferstecher]

Hallo zusammen,

wer kennt sich mit dem "DPI-Scaling" aus?

Für mich ist das ein neues Thema und ich stoße auf Probleme, auch weil ich mich mit dem Debuggen (auf zwei Systemen arbeiten) etwas schwer tue.

Mein Verständnis war eigentlich so, dass Lazarus für die im Designer angeordneten Controls die Größe beim Laden automatisch skaliert. Beim Laden und bei dpi-Änderung durch Aufruf von DoAutoAdjustLayout. Zumindest, wenn keine Ancor gesetzt sind. Und dass man sich um dynamisch erzeugte Controls selber kümmern muss, indem man entsprechend größere/kleinere Werte in Left/Top/Width/Height verwendet. Meine Vorstellung war auch, dass Left/Top/Width/Height jeweils die tatsächlichen Maße enthält, dass man also für ein Childcontrol eigentlich direkt bspw. Height vom Parent verwenden kann ohne eine Scalierung zu berücksichtigen, da ja Height vom Parent schon skaliert wurde. Aber genau das funktioniert bei mir in einem Fall nicht, es scheint als habe Height die unskalierte Größe bei tatsächlich skalierter Darstellung. In anderen Fällen funktioniert es allerdings schon. Mit einem Minimalbeispiel konnte ich es bisher nicht nachvollziehen, daher erstmal ohne Code. Vielleicht seht ihr ja auch schon aus meiner Beschreibung einen (oder mehrere) Denkfehler.

Was mir auch noch aufgefallen ist, ist dass
Form1.ScaleDesignToForm(Wert) immer als 1 skaliert, also "Wert" zurückgibt. Unterscheidet die LCL evtl zwischen skalierten und unskalierten Componenten?

Danke schonmal!

Achso:
Win7 120dpi/Win10 150dpi
Lazarus 3.2 mit aktiviertem dpi-Scaling und Designtime-dpi-Scaling

[wp_xyz]

Deine Beschreibung liest sich richtig. Ohne ein Beispiel-Projekt kann ich aber schlecht sagen, was falsch sein sollte.

Bei zur Laufzeit erzeugten Controls komme ich selbst immer wieder ins Schleudern, denn je nachdem wann eine Dimension verwendet wird (vor oder nach dem AutoAdjustLayout) muss man korrigieren oder nicht. Am einfachsten: Ausprobieren und auf verschiedenen Systemen testen (ich entwickle auf Windows normalerweise bei 96ppi und habe für Tests aber einen zweiten User sowie eine VM mit 144ppi). Dabei auch darauf achten, ob nicht zweimal skaliert wird.

Form1.ScaleDesignToForm(Wert) immer als 1 skaliert, also "Wert" zurückgibt. Unterscheidet die LCL evtl zwischen skalierten und unskalierten Componenten?

Ich glaube eher, das ist dafür gedacht, falls jemand das Designtime-Scaling deaktiviert ("Force DPI scaling at designtime" OFF in den IDE-Optionen) hat, so dass DesigntimePPI und PixelsPerInch unterschiedlich sind (denn das ScaleDesignToForm korrigiert eine Dimension genau im Verhältnis dieser beiden Angaben).

[kupferstecher]

Danke schonmal für die Antwort. Gestern habe ich auch noch etwas rumprobiert und komme der Sache etwas näher. Es scheint dass sich Left/Top/Width/Height wenn von innerhalb des Konstruktors Create aufgerufen anders verhält. Das könnte mit dem von dir erwähnten AutoAdjustLayout zusammenhängen.
Ich muss ertmal noch ein paar Versuche machen, ich hoffe heut Abend komm ich dazu. Dann sollte es auch ein aussagekräftiges Minimalbeispiel geben.

[kupferstecher]

So, jetzt bin ich endlich ein Stück weiter und es gibt auch ein Minimalbeispiel. Es scheint so, dass für Dinge, die innerhalb von TForm.OnCreate passieren, die Werte Left/Top/Width/Height entspechend der DesigntimePPI angegeben werden müssen und automatisch skaliert werden und danach dann die tatsächlichen Werte. Im englischen Forum habe ich gefunden, dass es eine Umschaltung in TForm.Show gibt. Kurz danach feuert dann auch AutoAdjustLayout für das Control. Und da ist mir jetzt nicht ganz klar, wie das verwendet werden kann. So wie ich das verstehe sollte das ja zur Anpassung während das Programm läuft verwendet werden können. Allerdings findet schon die automatische Anpassung nach dem Erzeugen statt, wenn man dann auf AutoAdjustLayout reagiert, hat man doppelt, also überskaliert.

-> Weiß jemand wie das gedacht ist?

Kurz dachte ich, dass die automatische Skalierung von 96dpi (100%) auf DesignTimePPI ist und AutoAdjustLayout dann auf die tatsächliche/aktuelle Skalierung, ist aber auch nicht so, ist beides von DesignTimePPI auf Aktuelle.

Ein Fallstrick über den ich hier auch gestolpert bin, ist ein Hintergrundbild in Create zu erstellen und später zu verwenden, weil die Bitmap die automatische Skalierung ja nicht mitmacht. Das ließe sich aber vielleicht in AutoAdjustLayout unterbringen.

[wp_xyz]

Bin nicht sicher, ob ich verstehe, was das Demo-Projekt zeigen soll.

AutoAdjustLayout ist eigentlich nicht dafür gedacht, dass es vom User aufgerufen wird. Das macht die LCL automatisch im Zuge des Erzeugungsprozesses einer Komponente (in TForm.AfterConstruction, das kommt nach dem OnCreate-Handler), oder wenn später einmal das Formular auf einen Monitor mit anderer Auflösung gezogen wird. Im ersteren Fall ist zu diesem Zeitpunkt das Formular schon von der lfm-Datei gelesen, und die LCL kennt die PixelsPerInch (oder DesigntimePPI?), in denen das Formular gespeichert wurde. Daher werden dann im AutoAdjustLayout alle bisher gefundenen Längenangaben von diesen PPI auf die aktuell gültigen umgerechnet. Wenn du später Längenangaben machst, z.B. erst in OnShow, dann werden diese als Pixel für die aktuell gültigen PPI interpretiert - auf einem HighRes-Display fallen diese dann entsprechend kleiner aus als auf einem Standard-Monitor. Stattdessen musst du eine manuelle Umrechnung aufrufen: Scale96ToScreen, Scale96ToForm oder Scale96ToFont; diese nehmen an, dass die zu skalierende und als Argument angegebene Dimension unter 96ppi zu verstehen ist. Wenn du also zur Laufzeit, z.B. im OnShow Event des Formulars, ein manuell erzeugtes Control so weit vom linken rand entfernt positionieren möchtest, dass der Abstand bei 96 ppi 100 Pixel wäre und bei jeder Auflösung genausoviele Millimeter beträgt, dann musst du Scale96ToScreen(100) aufrufen.

Wenn du selbst Komponenten schreibst, und "innere" Dimensionen verwendest (z.B. einen Abstand zwischen Elementen, einen Randabstand, ...) dann musst du DoAutoAdjustLayout überschreiben; das wird von AutoAdjustLayout aus aufgerufen und führt für deine Komponente die PPI-Skalierung der noch unbekannten/unbehandelten Dimensionen durch; der Skalierungsfaktor wird als Argument mitgeliefert. Wenn deine Komponente auch noch Fonts enthält, die nicht "Font" heißen (sondern z.B. "TitleFont", "CaptionFont", "DetailFont", oder so), dann musst du auch die Methoden ScaleFontsPPI und FixDesignFontsPPI überschreiben. Durchsuche den Code im LCL-Ordner der Lazarus-Installation nach Beispielen.

Bitmaps sind für die Skalierung ein Problem, weil sie Pixel für Pixel angezeigt werden, also auf einem High-Res-Monitor entsprechend klein ausfallen. Du kannst dem vorbeugen, indem du Bitmaps mit StretchDraw anzeigst (anstatt mit Draw) und die Größe des Zielrechtecks aus den aktuellen PPI ausrechnest. Natürlich ist das, gerade beim Heraufskalieren mit einem entsprechenden Qualitätsverlust verbunden. Oder du stellst mehrere Bildgrößen zur Verfügung und bestimmst, basierend auf den aktuellen PPI, welche Größe per Draw angezeigt werden soll. Ähnlich macht es die LCL in der TImageList, wenn deren Scaled-Property auf true gesetzt ist.

Leider ist das Thema LCLScaling für Komponentenschreiber im wiki nicht gut dargestellt. "Man" müsste mal ein Tutorial schreiben, in dem alle wesentlichen Punkte angesprochen werden.

[kupferstecher]

Das Demoprojekt sollte zeigen, wie sich ein inneres Control im Vergleich zu einem Container-/Parent-Control verhält. Ich bin dann dadurch erst draufgekommen, dass meine Bitmap nur zu klein ist, das Control selber aber schon skaliert war. Außerdem soll es zeigen, wann AutoAdjustLayout aufgerufen wird. DoAutoAdjustLayout war mir gar nicht bewusst. Dass man das (beide) nicht selber aufruft, habe ich mir gedacht, ich wollte einfach überschreiben um selber 'händisch' auf die Skalierung zu reagieren. Und das geht auch tatsächlich, wenn man inherited weg lässt. Die automatische Skalierung ist sicher in den meisten Fällen sinnvoll, Position und Größe sollten ja stimmen. Allerdings kommt man scheinbar in Rundungsfehler, bspw. bei einem Parentelement mit Höhe 32 und einem Childelement, das von Top=4 bis ganz nach unten geht, also eine Höhe von 28 hat. Nach Skalierung mit dem Faktor 1,2 hat das Parentelement eine Höhe von 38, und das Childelement Top=5 und Height= 34, ragt also unten einen Pixel über das Parentelement raus. Man muss die Positionen also selbst berechnen, oder korrigieren.

Es gäbe die Möglichkeit, Inherited wegzulassen (1). Aber sollte DoAutoAdjustLayout oder AutoAdjustLayout verwendet werden? DoAutoadjustLayout wird von AutoAdjustLayout im Inherited aufgerufen. Letzteres ruft auch noch die Children auf, was meistens sinnvoll ist. Alternativ (2) könnte man Inherited mit der automatischen Skalierung belassen und entweder die ursprünglichen Bounds-Werte zwischenspeichern oder hier im Beispielfall wäre wohl das einfachste, die Höhe des Childelements nach der automatischen Skalierung anzupassen, also Child.Height:= Parent.Height-Child.Top; (3)
Bei (2) würde ich AutoAdjustLayout bevorzugen, weil die Childs und anderes in Inherited skaliert werden, man hat also wirklich das komplette vorher/nachher in der überschriebenen Funktion AutoAdjustLayout.

Die Bitmap-Geschichte habe ich verstanden, muss es aber erst noch testen.

Was das Wiki betrifft habe ich mir vorgenommen etwas zu ergänzen, muss aber erst selber noch etwas klarer werden.

--
Noch ein anderes Thema, im Wiki wird ja empfohlen, dass man immer in 100% Skalierung entwickelt. Mir scheint das prinzipiell auch sinnvoll, weil man bei laufzeiterzeugten Controls eigentlich auch die Werte der DesigntimePPI angeben müsste. Wechselt man aber die PPI während der Entwicklung, ändern sich die PPI im Designer, hart codierte (laufzeiterzeugte Controls) bleiben aber mit ihren Werten gleich. Man müsste im Code also noch zwischen 100% und DesignTimeDPI skalieren oder halt in 100% entwickeln. Andererseits ist es für mich nicht unbedingt praktikabel bei 96dpi (100%) zu entwickeln, weil das auf den Bildschirmen einfach zu klein ist. Ich denke Lazarus sollte bei skalierten Programmen auch im Form-Designer skalieren und alle Koordinaten im Objektinspektor als 100% angeben und nicht entsprechend dem DesignTimePPI-Wert. Wenn du das auch so siehst, würde ich das im englischen Forum mal vorschlagen.

[wp_xyz]

Man muss die Positionen also selbst berechnen, oder korrigieren.

Oder die Positionen und Größen mit dem Anker-Editor festlegen. Das ist zwar umständlicher, sorgt aber für ein stabiles Layout, das sich anpasst, wenn Microsoft den Windows-Font mal wieder ändert, oder der Linux-User ein anderes Desktop-Theme auswählt, oder der User nach Linux/Mac wechselt und dort komplett andere Schriftgrößen vorfindet.

Es gäbe die Möglichkeit, Inherited wegzulassen (1). Aber sollte DoAutoAdjustLayout oder AutoAdjustLayout verwendet werden? DoAutoadjustLayout wird von AutoAdjustLayout im Inherited aufgerufen. Letzteres ruft auch noch die Children auf, was meistens sinnvoll ist. Alternativ (2) könnte man Inherited mit der automatischen Skalierung belassen und entweder die ursprünglichen Bounds-Werte zwischenspeichern oder hier im Beispielfall wäre wohl das einfachste, die Höhe des Childelements nach der automatischen Skalierung anzupassen, also Child.Height:= Parent.Height-Child.Top; (3)
Bei (2) würde ich AutoAdjustLayout bevorzugen, weil die Childs und anderes in Inherited skaliert werden, man hat also wirklich das komplette vorher/nachher in der überschriebenen Funktion AutoAdjustLayout.

Wenn du weißt, was du tust, kannst du alles machen. Wenn du Inherited weglässt, musst halt du dich darum kümmern, dass der geerbte Code ausgeführt wird. Oder eben bewusst darauf verzichten, und alles (oder einiges) ganu anders machen. ABER: Das Thema Größenänderung/Layout ist so kompliziert, so ich nur im äußersten Notfall vom geebneten Weg abweichen würde.

Noch ein anderes Thema, im Wiki wird ja empfohlen, dass man immer in 100% Skalierung entwickelt.

Ich weiß nicht, wer das reingeschrieben hat. In letzter Konsequenz ist es, glaube ich, nicht richtig. Möglicherweise stammt es aus der Zeit, als der Designer noch nicht skaliert war.

Ich denke Lazarus sollte bei skalierten Programmen auch im Form-Designer skalieren

Das tut er ja (sofern das entsprechende Kästchen in den Eigenschaften des Designers gesetzt ist). Das Problem sind eher die zur Laufzeit gesetzten Dimensionen. Wie im vorigen Post schon gesagt: Wenn du nach OnCreate eine Komponente an den Ort Left = 100 verschiebst, und das ist perfekt zu anderen Controls ausgerichtet, dann gilt das nur für dich und deinen Monitor. Bei mir, mit 96ppi, nehmen 100 Pixel viel mehr Platz ein als bei dir mit vielleicht 192 ppi, und die perfekte Ausrichtung wird nicht mehr passen (denn die anderen Controls werden ja skaliert).

Wenn du das auch so siehst, würde ich das im englischen Forum mal vorschlagen.

Besser auf der Lazarus-Mailing-Liste, damit die Chance größer ist, dass Ondrej Pokorny es sieht, der das LCLScaling geschrieben hat.

[kupferstecher]

Man muss die Positionen also selbst berechnen, oder korrigieren.

Oder die Positionen und Größen mit dem Anker-Editor festlegen.

War es nicht so, dass Maße, die vom Anchor abhängig sind, nicht skaliert werden?

ABER: Das Thema Größenänderung/Layout ist so kompliziert, so ich nur im äußersten Notfall vom geebneten Weg abweichen würde.

Ja, stimmt. Nur wo sollte nun die individuelle Skalierung vorgenommen werden, in AutoAdjustLayout oder DoAutoAdjustLayout?

Noch ein anderes Thema, im Wiki wird ja empfohlen, dass man immer in 100% Skalierung entwickelt.

Ich weiß nicht, wer das reingeschrieben hat. In letzter Konsequenz ist es, glaube ich, nicht richtig. Möglicherweise stammt es aus der Zeit, als der Designer noch nicht skaliert war.

Kann natürlich sein. (LCL-)Komponenten müssen ja auch bei anderer Designtime-PPI funktionieren. Nur hat man dann doch genau das Problem, dass man eincodierte Maße erst noch auf DesignTimePPi umrechnen muss, zumindest wenn die automatische Skalierung zwischen DesignTimePPi und Tatsächlicher skaliert.

Das tut er ja (sofern das entsprechende Kästchen in den Eigenschaften des Designers gesetzt ist).

So wie ich das verstehe, sind in der Projektdatei die Maße in Bezug auf die letzte DesignTimePPI gespeichert. Beim laden wird dann skaliert und der Objektinspektor zeigt die tatsächlichen Maße an. Ich denke es wäre besser, wenn der Objektinspekteur die Maße bei 96dpi anzeigen würde (bei gleichzeitig skalierter Form) und DesigntimePPI damit immer 96 wäre. Was die Laufzeit angeht, wäre das Scaling damit rückwärtskompatibel, was es für den Designer für Auswirkungen hätte kann ich jetzt nicht abschätzen, auch der OI müsste verändert werden, da er ja bei jeder Änderung/ jedem Zugriff skalieren müsste.

Besser auf der Lazarus-Mailing-Liste, damit die Chance größer ist, dass Ondrej Pokorny es sieht, der das LCLScaling geschrieben hat.

Naja, dann warte ich doch besser erstmal noch.

[wp_xyz]

Man muss die Positionen also selbst berechnen, oder korrigieren.

Oder die Positionen und Größen mit dem Anker-Editor festlegen.

War es nicht so, dass Maße, die vom Anchor abhängig sind, nicht skaliert werden?

Maße, die vom Anchor abhängig sind? Ich sehe das genau anders herum: Der Anchor definiert Controls und Seiten, an denen das andere Control hängt, sowie Abstände, nämlich die BorderSpacings, und diese werden skaliert.

ABER: Das Thema Größenänderung/Layout ist so kompliziert, so ich nur im äußersten Notfall vom geebneten Weg abweichen würde.

Ja, stimmt. Nur wo sollte nun die individuelle Skalierung vorgenommen werden, in AutoAdjustLayout oder DoAutoAdjustLayout?

Normalerweise in DoAutoAdjustLayout. Denn das neue Control ist von einem anderen abgeleitet, und man möchte die Skalierung der geerbten Dimensionen ja übernehmen. Nur wenn du das nicht willst, musst du in AutoAdjustLayout und damit früher eingreifen.

Noch ein anderes Thema, im Wiki wird ja empfohlen, dass man immer in 100% Skalierung entwickelt.

Ich weiß nicht, wer das reingeschrieben hat. In letzter Konsequenz ist es, glaube ich, nicht richtig. Möglicherweise stammt es aus der Zeit, als der Designer noch nicht skaliert war.

Kann natürlich sein. (LCL-)Komponenten müssen ja auch bei anderer Designtime-PPI funktionieren. Nur hat man dann doch genau das Problem, dass man eincodierte Maße erst noch auf DesignTimePPi umrechnen muss, zumindest wenn die automatische Skalierung zwischen DesignTimePPi und Tatsächlicher skaliert.

Wieso? Du bekommst die gerade gültigen Dimensionen zu Gesicht. Wenn ich mit 96ppi einen Button bei Left=100 setze, das Formular speichere, und du es bei 192ppi wieder öffnest, steht bei dir der Wert 200 bei der Left-Property. Aber vielleicht verstehe ich den Punkt nicht richtig.

Das tut er ja (sofern das entsprechende Kästchen in den Eigenschaften des Designers gesetzt ist).

So wie ich das verstehe, sind in der Projektdatei die Maße in Bezug auf die letzte DesignTimePPI gespeichert. Beim laden wird dann skaliert und der Objektinspektor zeigt die tatsächlichen Maße an. Ich denke es wäre besser, wenn der Objektinspekteur die Maße bei 96dpi anzeigen würde (bei gleichzeitig skalierter Form) und DesigntimePPI damit immer 96 wäre. Was die Laufzeit angeht, wäre das Scaling damit rückwärtskompatibel, was es für den Designer für Auswirkungen hätte kann ich jetzt nicht abschätzen, auch der OI müsste verändert werden, da er ja bei jeder Änderung/ jedem Zugriff skalieren müsste.

Ich denke, es würde mich gewaltig irritieren... Aber kann man das nicht erreichen, indem man "Force DPI Scaling in Design Time" in den Options des Designer-Formulars ausschaltet? Hab's noch nie probiert...

[kupferstecher]

War es nicht so, dass Maße, die vom Anchor abhängig sind, nicht skaliert werden?

Maße, die vom Anchor abhängig sind? Ich sehe das genau anders herum:

Habe es jetzt nochmal probiert, ja, funktioniert. Allerdings war es davor mal bei einer Form-In-Form-Anwendung so, dass geanchorte Controls (z.B. [akTop,akLeft,akRight]) nicht automatisch skaliert wurden. Muss ich nochmal schauen, ist aber natürlich ein Spezialfall. Allerdings habe ich auch irgendwas zum Thema Anchors und Scaling gelesen. Naja...

Wieso? Du bekommst die gerade gültigen Dimensionen zu Gesicht. Wenn ich mit 96ppi einen Button bei Left=100 setze, das Formular speichere, und du es bei 192ppi wieder öffnest, steht bei dir der Wert 200 bei der Left-Property. Aber vielleicht verstehe ich den Punkt nicht richtig.

Wenn ich in der FormCreate einen Wert von 100 eintrage, wird das als Wert relativ zur DesignTimePPI interpretiert und entsprechend auf die tatsächlichen PPI skaliert. Bei einer DesignTimePPI von 96 ergibt das skaliert eine anderes Maß als bei einer DesignTimePPI 120. Aber ja, man muss halt mit dem richtigen Faktor skalieren, sollte TControl.Scale96ToForm sein. So wie ich das sehe, wird der auch in AutoAdjustLayout dem aktuellen Wert angepasst*. Wäre also wieder egal, wann es aufgerufen wird, und das ist ja das entscheidende.

Ich denke, es würde mich gewaltig irritieren... Aber kann man das nicht erreichen, indem man "Force DPI Scaling in Design Time" in den Options des Designer-Formulars ausschaltet? Hab's noch nie probiert...

Das Ausschalten bewirkt, dass das Formular unabhängig vom Bildschirm immer mit den Werten, die in der lpi stehen, geladen wird, also auf jeder DPI-Einstellung gleich viel Pixel belegt. Im Objektinspektor sind aber immer, ob ein oder aus, die Anzahl der tatsächlichen Pixel angezeigt (Soweit ich das verstehe). Für Nicht-Skalierte Anwendungen ist das wichtig, wenn man zwischen Systemen wechselt. Ist m.E. auch ein Problem, dass das eine IDE-Einstellung und keine Projekteinstellung ist, so kann man kaum skalierte und unskalierte Programme mit dem selben Lazarus entwickeln.

Vielleicht ist das wie ich mir es vorstelle wirklich nicht nötig/sinnvoll. Vorteil wäre eben, dass man kein DesignTimePPI mehr hätte, weil das immer 96 wäre. Also nur noch einen Skalierfaktor. Ich denk, das würde vieles vereinfachen.

*EDIT: Nein, da stimmt was nicht. ScaleDesignToForm(100) gibt sowohl vor als auch nach AutoAdjustLayout den Wert 100 zurück.
EDIT2: Nach formCreate gibt ScaleDesignToForm(100) dann 120 zurück, wird also angepasst, m.E. aber zu spät. Wobei man innerhalb von AutoAdjustLayout mit den Parametern arbeiten kann.