DPI-Einstellung oder Schriftgrad des Desktop

[AUGE_OHR]

Man kann den Anwender nicht daran hindern, eine andere Bildschirmauflösung zu wählen.

ok wir reden von 2 verschiedenen Sachen die der User machen kann.

bei DPI-aware geht es um folgenden Effekt :

aus den Snapshot kann man sehen das die "echte" Auflösung 1920x1200 ist, mit AppDeskTop():CurrentSize() wird aber 1280x800 bei 150% ausgegeben
die "Berechnungen" laufen also auf einen "virtuellen" Desktop (Win7 ab 125%) wo man nur 96 DPI hat. die Applikation verändert sich ja so (150%)

Layout1280_150.jpg (176.25 KiB) 7877 mal betrachtet

die Appkation wird durch DWM*** vergrössert was jedes XbParts samt Font betrifft.
*** https://msdn.microsoft.com/de-de/librar ... 85%29.aspx

wenn das nicht mehr passt ... man müsste die XbParts & Schrift verkleinern ...
aber dafür benötige ich den Faktor := nDPI / 96 welcher sich aus der "echten" Auflösung und dem "virtuellen" Desktop ergibt.

wenn eine Applikation, mit einen angepassten Manifest oder Checkbox,

DPI_deaktivieren.jpg (81.19 KiB) 7877 mal betrachtet

DPI-aware "fest" gemacht wurde dann wird DWM (?) abschaltet und man bekommst mit AppDeskTop():CurrentSize() 1920x1024 als Monitor Grösse und die Applikation läuft unter 150% mit 144 DPI welche virtuell dann 96 DPI sind also die "echten" Werte.

Layout1280_disable_150.jpg (151.49 KiB) 7877 mal betrachtet

---

nun gibt es auch den Fall anders-rum wie du beschreibst :
Monitor wurde grösser aber User lässt 100% und möchte das die Xbase++ Applikation grösser wird bzw. Bildschirmauflösung wurde geändert.

die "Berechnung" eines X,Y "Faktor" ist genau das selbe wie ein oDlg:DrawingArea:Resize und überflüssig wenn man den Layoutmanager() verwendet mit

Code: Alles auswählen

o:layoutAlign  := XBP_LEFTEDGE+XBP_TOPEDGE+XBP_RELWIDTH+XBP_RELHEIGHT+XBP_RELXPOS+XBP_RELYPOS

(siehe Demo DXE_Button Source )

bei einem XbpBrowse() / XbpQuickBrowse() unterstützt der Layoutmanager leider noch nicht "column position and size" PDR 6682

nun bezieht sich Pos / Size nur auf die XbParts aber NICHT auf die Schrift !
! Note : Bitmap Fonts taugen NICHT zum skalieren also nur o:vector := .T.

es ist für Xbase++ Applikationen das selbe Font Problem wie es unter Windows Vista war wo DWM eingeführt wurde.
leider hat Alaska das Font Problem nicht in den Layoutmanager integriert ... also selber eine CLASS xyz FROM LayoutManager schreiben.

[brandelh]

DPI hängt von der physischen Auflösung des Moniotors ab, wäre die immer gleich, würden die Pannels bis zur Decke reichen.
Ein 4 K Monitor hat bei gleichen "DPI" Einstellungen von Windows eine winzige Darstellung, also geht man auf 150 % ... wieviel Platz das braucht ist hardware abhängig.
Unsere Fenster basieren nunmal auf dots

[Dieter]

Hallo Jimmy,

als Programmierer habe ich keinen Einfluss, wie groß ein Pixel auf einem Bildschirm eines Anwenders sein wird. Somit kann ich auch die tatsächliche DPI oder PPI beim Anwender garn nicht berechnen. Diese interessiert auch gar nicht. Klar ist, dass bei kleinen Monitorgrößen mit sehr kleinen Pixeln oft nicht mehr mit einem Programm gearbeitet werden kann. Also müssen in solchen Fällen die Pixel größer gemacht werden ( im Umkehrschluss weniger große Pixel --> PPI wird kleiner). Dies kann jeder Anwender über das Betriebsystem. Zu verhindern, dass die eigene Anwendung von der Skalierung durch das Betriebsystem ausgenommen wird, halte ich für keine so gute Idee. Der Programmieraufwand steigt dann erheblich, da man sich auch um Schrift- und Icon-Größen kümmern sollte. Ich gehe mittlerweile davon aus, dass du diese Vorgehenweise beschreitest und du deshalb auch solche Termini wie

der "echten" Auflösung und dem "virtuellen" Desktop

benutzt.
So wie es z. B. Jan macht, ist es auf jeden Fall einfacher und produktiver.

@ Hubert
Du hast Recht.
Trotzdem kann es Probleme mit den Schriften geben, die nicht in die XbParts passen.

[AUGE_OHR]

So wie es z. B. Jan macht, ist es auf jeden Fall einfacher und produktiver.

und was macht er "anders" ?

die beiden Manifest Files von Jan bewirken genau das selbe wie mit der Checkbox.
der "Zoom" Faktor funktioniert nur für die Berechnung "von aussen".

man muss mit BEIDEN Situationen rechnen und benötigt somit "mehr" als nur den "Zoom" Faktor der "von innen" berechnet immer nur 1 ergibt !

---

was aber trotzdem noch fehlt ist die Font Grössen Anpassung welche man zwar mit dem "Zoom" Faktor multiplizieren kann aber damit auch "ungültige" (Dezimalstellen etc) Font Grössen bekommt wo sich das OS() dann die nächst "passende" Grösse simuliert.

andere Möglichkeit : man lässt den User den Font / Grösse wählen und "berechnet" daraus die Dialog Grösse

Code: Alles auswählen

   aSize[2] := ( nFontSize * nLines ) + nFrameSize + nBorderpadding
   aNewSize := oDlg:calcFrameRect({0,0,aSize[1],aSize[2]})
   aSize[2] := aNewSize[4] - aNewSize[2]
   oDlg:SetSize([aSize)

[Dieter]

Hallo Jimmy,

und was macht er "anders" ?

Ich nehme an, dass er einen Zoomfaktor berechnet und damit alle xbparts um diesen Faktor vergrößert (oder verkeinert). Um die Schriften braucht er sich dann nicht mehr zu kümmern.

"Zoom" Faktor der "von innen" berechnet immer nur 1 ergibt

Kann ich nicht nachvollziehen, da ich auch Werte <>1 errechnen kann.

andere Möglichkeit : man lässt den User den Font / Grösse wählen und "berechnet" daraus die Dialog Grösse

Was machst du mit der Menu-Schrift und den Icons?

[AUGE_OHR]

Ich nehme an, dass er einen Zoomfaktor berechnet und damit alle xbparts um diesen Faktor vergrößert (oder verkeinert). Um die Schriften braucht er sich dann nicht mehr zu kümmern.

leider hast du die erste "Bedingung" übergangen um ein Programm DPI-aware "fest" zu machen

Vorbereiten: Grundsätzlich ist es erforderlich, die Manifest des Programmes zu erweitern.

und auf die Schrift ist Jan nicht eingegangen.

"Zoom" Faktor der "von innen" berechnet immer nur 1 ergibt

Kann ich nicht nachvollziehen, da ich auch Werte <>1 errechnen kann.

hm ... das sagen mir die Bildschirmfoto von dir aber etwas anderes : er wird bei beiden Bildern 96DPI angezeigt.

das ändern der Bildschirmauflösung verändert nicht den DPI Wert wenn der User statt 1600x1200 nur 1024x768 einstellt !
was sich ändert ist deine "fixe" Grösse ( angenommen 800x600 ) zu AppDeskTop():CurrentSize() woraus du deinen "Zoom +" Faktor errechnest.

den selben "optischen" Effekt kann der User aber auch erreichen wenn er 150% "Vergrösserung" einstellt
d.h. wenn du mit einem (echten) Lineal auf dem Bildschirm nachmisst ist deine Applikation genauso gross in mm.

es gibt jedoch einen (erheblichen) Unterschied : die Schrift Grösse !

bei 150% übernimmt der DWM das rendern was die Controls UND den Font betrifft. bei der "Zoom +" Methode musst du dich um die Controls und Font selbst kümmern.

nun ist die "Zoom +" Methode nichts anderes als oDlg:DrawingArea:Resize z.b. wenn das Fenster maximiert wird.
genau das macht aber der Layoutmanager() d.h. die "Zoom +" Methode und das "berechnen" für Pos / Size ist obsolet.

was der Layoutmanager aber nicht macht ist die "Berechnung" der Font Grösse ... aber das ist ein anderes Thema

andere Möglichkeit : man lässt den User den Font / Grösse wählen und "berechnet" daraus die Dialog Grösse

Was machst du mit der Menu-Schrift und den Icons?

das Menu ist in dem Sinn kein XbPart und der Font wird vom OS() gewählt. Hier kann man nur Ownerdraw verwenden wenn man "eingreifen" will.

[Dieter]

Hallo Jimmy,

leider hast du die erste "Bedingung" übergangen um ein Programm DPI-aware "fest" zu machen

Ich benutze ja auch ein Manifest ohne DPI-Awareness, damit die DPI-Virtualisation durch das Betriebssystem erfolgen kann.

Code: Alles auswählen

hm ... das sagen mir die Bildschirmfoto von dir aber etwas anderes : er wird bei beiden Bildern 96DPI angezeigt.

Ich hatte ja auch geschrieben, dass die 96 DPI richtig sind! Außerdem hatte ich doch bereits erwähnt, dass ein Programmierer keinen Einfluss hat, wie groß ein Pixel auf einem Bildschirm eines Anwenders sein wird. Die programmierte Anzahl der Pixel sind in beiden Bildschirmfotos gleich. Der Unterschied liegt lediglich in der Größe eines Pixels.
Damit du siehst was ich meine, füge ich noch ein Bildschirmfoto dazu:

120 DPI bei 125% Vergrößerung

1920x1200-125%.png (23.25 KiB) 7830 mal betrachtet

In der Anzeige wurde der Vergrößerungsfaktor auf 125% eingestellt. Das Desksize.prg-Fenster ist genau so groß wie bei 1920x1200-100%. Dein Programm desksize.prg berechnet richtigerweise 120 DPI. Bei der DPI-Virtualisation stimmen jetzt die Pixelangaben für die xbParts nicht mehr, wenn ein Programm von 96 DPI ausgeht. Der Zoomfaktor 120/96 = 1,25 korrigiert den Fehler. Da alle xbparts größer werden, muss logischerweise auch das Fenster größer werden. Auch bei Einsatz der DPI-Virtualisation muß sich der Programmierer um um eine dpi-sichere Programmierung kümmern.

[Jan]

und auf die Schrift ist Jan nicht eingegangen.

Jimmy,

in dem Artikel in der Wissensbasis, auf den hier in der Diskussion verwiesen worden ist, wird sehr wohl auf die Schriftgröße eingegangen. Das die nämlich durch den entsprechenden Eintrag in der Manifest automatisch angepasst wird.

Die Anpassung geschieht in zwei Schriften:
1) Manifest. Dadurch wird u. a. die Schriftgröße angepasst
2) Berechnen. Hat man die DPI ausgelesen, kann man daraus ein Verhältnis zu 100%-Darstellung berechnen, und dieses Verhältnis auf alle GUI-Element-Größen anwenden.

Macht man nur Schritt 1, dann wird die Schrift so groß, das z. B. irgendwann die Buttonbeschriftungen einfach nicht mehr auf den Button passen. Der muß also auch größer werden, was eben in Schritt 2 geschieht.

Schritt 2 bedeutet natürlich nur, das die Elemente an die eingestellte % angepasst werden. Das hat nichts mit Skalieren zu tun, wenn z. B. der Dialog manuell vergrößert wird und die Children dann automatisch mit größer werden sollen. Das kann man unter der 2.0 aber relativ gut mit dem Layout-Manager hinbekommen (obwohl der bei mir an einigen Stellen noch heftig zickt, da muß ich noch mit Alaska drüber reden)

Jan

[Dieter]

Hallo Jan,

die Schrift wird meiner Meinung nach nur dann automatisch skaliert, wenn in der Manifest-Datei nicht dpiAware=true vereinbart ist. Bist du dir sicher, dass die Manifest-Datei so in deiner Exe eingebunden ist?
Setze den Wert doch mal auf false und prüfe, ob sich dein Programm verändert.

[AUGE_OHR]

In der Anzeige wurde der Vergrößerungsfaktor auf 125% eingestellt.

der Fall 125% unter Windows 7 ist ein "besonderer" Fall da er wie unter XP arbeitet. versuch mal 150%.

[AUGE_OHR]

in dem Artikel in der Wissensbasis, auf den hier in der Diskussion verwiesen worden ist, wird sehr wohl auf die Schriftgröße eingegangen. Das die nämlich durch den entsprechenden Eintrag in der Manifest automatisch angepasst wird.

Die Anpassung geschieht in zwei Schriften:
1) Manifest. Dadurch wird u. a. die Schriftgröße angepasst
2) Berechnen. Hat man die DPI ausgelesen, kann man daraus ein Verhältnis zu 100%-Darstellung berechnen, und dieses Verhältnis auf alle GUI-Element-Größen anwenden.

Macht man nur Schritt 1, dann wird die Schrift so groß, das z. B. irgendwann die Buttonbeschriftungen einfach nicht mehr auf den Button passen. Der muß also auch größer werden, was eben in Schritt 2 geschieht.

wie ich ja sagte wird bei 1.) durch DWM die Pos / Size und Font beeinflusst.
es geht um 2.) die Skalierung eines Font welcher mit XbpFont nur INT() Werte nimmt der "Formel" nicht aufgeführt ist ( siehe Thread XbpFont() -> API Font )

[Dieter]

Hallo Jimmy,

der Fall 125% unter Windows 7 ist ein "besonderer" Fall da er wie unter XP arbeitet. versuch mal 150%.

150% habe ich schon beschrieben -> 96 DPI
Wenn Windows bei 150% auf meinem Entwicklungsrechner nicht die Auflösung auf 1280x800 Pixel herabsetzen würde und stattdessen die Auflösung 1920x1200 beibehalten würde und die Schrift von z. B. 12 Pt = 16 Pixel auf 18 Pt = 24 Pixel heraufskalieren würde, dann erst hätte man 144 DPI. Die Schriften sind aber bei 100 % und bei 150 % jeweils 16 Pixel hoch. Der Korrekturfaktor ist demnach 96/96=1. Der Programmierer braucht eigentlich gar nichts machen. Der Anwender hat aber trotzdem eine größere Schrift, weil ein Pixel um Faktor 1,5 größer ist.

Originalauszug aus einem Microsoftartikel:

Seit vielen Jahren verwendet Windows die folgende Konvertierung: Ein logisches Zoll entspricht 96 Pixeln.

Deshalb sind 100% wohl immer 96 DPI. Es ist aber ein Irrtum anzunehmen, dass 150% immer 144 DPI sind.

[AUGE_OHR]

Hi Dieter,

weil ein Pixel um Faktor 1,5 größer ist.

ein Pixel kann nicht grösser werden
du machst einen Fehler bei der Überlegung mit den Pixel und Monitor Bildschirmauflösung.

wenn du einen 1920x1200 mit native 1:1 Einstellung hast dann stimmt Font:height = Pixel.
wenn du den Bildschirm auf 1280x800 einstellst werden 1.5 x Pixel für den selben Font verwendet !

das sieht mit Raster Font (o:vector := .F. default ) natürlich schrecklich aus also "ausgleichen" per Cleartype ...

ein deutlich besseres Ergebnis für eine 1280x800 Darstellung bekommt man ab Windows 7 mit der 150% "Vergrösserung"
wo der DWM für das rendern, was Antialiasing enthält, zuständig ist.

und jetzt kommen wir zur Xbase++ Applikation wie die aussieht ...

Originalauszug aus einem Microsoftartikel:

Seit vielen Jahren verwendet Windows die folgende Konvertierung: Ein logisches Zoll entspricht 96 Pixeln.

Deshalb sind 100% wohl immer 96 DPI. Es ist aber ein Irrtum anzunehmen, dass 150% immer 144 DPI sind.

auch da musst du den wieder auf die Anzahl der Monitor Pixel x 1.5 sehen die es "mehr" pro "logischen" (!!!) Zoll gibt.

XP_DPI100.JPG (18.61 KiB) 7787 mal betrachtet

XP_DPI150.JPG (21.39 KiB) 7787 mal betrachtet

p.s. versuch mal unter Windows 10 den Menuepunkt zum ändern der Bildschirmauflösung zu finden ...
der User kommt nur bis zum Slider (Schiebeschalter) wo er die Vergrösserung einstellen kann.

[Dieter]

Hallo Jimmy,

wir unterscheiden uns ja nur in der Interpretation wieviele Pixel auf dem Bildschirm des Anwenders sind. Windows liefert aber meine erwarteten DPI-Werte, die damit auch meine Sichtweise bestätigen. In allen Xbase-Programmen werden die Bildschirmpixel wie folgt berechnet:

Code: Alles auswählen

aSize := AppDeskTop():CurrentSize()

Du gehst aber bei deinen Berechnungen immer von der nativen Auflösung des Bildschirmes aus. Wenn du in deinen Programmen (dpi-aware) damit klar kommst, dann ist doch alles in Ordnung!
Mit deinem Programm desksize.exe habe ich auf einem Windows 8.1-Rechner mit 30-Zoll-Bildschirm die Bildschirmpixel und die von Windows gelieferten DPI-Werte ausgeben lassen. Hier die Ergebnisse:
100% 2560x1600 96 DPI
125% 2560x1600 120 DPI
150% 1707x1067 96 DPI
200% 1280x800 96 DPI
250% 1024x640 96 DPI
135% 1890x1182 96 DPI

Man sieht, dass fast immer 96 DPI herauskommen. Also könnte auch eine einfache Strategie sein, dass die xbparts 25 % größer angelegt werden, sodass die 120 DPI-Schriften dort hineinpassen. Das geht natürlich nur, wenn man auf dpi-aware verzichtet. Hat jemand einen 4 K-Monitor und kann feststellen, ob Werte größer 120 DPI überhaupt von Windows ausgeben werden?

[AUGE_OHR]

wir unterscheiden uns ja nur in der Interpretation wieviele Pixel auf dem Bildschirm des Anwenders sind.

ein Pixel ist ein Pixel ...

... ob Werte größer 120 DPI überhaupt von Windows ausgeben werden?

wie ich schon sagte bekommt man > 125% nur noch 96 DPI weil es sich um einen virtuellen Desktop handelt.

p.s. teste es mal unter Windows 10 denn dort gibt es nur noch den virtuellen Desktop.