Physisches Bildraster eines Monitors erfahren?

[PeterPanino]

Ich habe extra den Ausdruck "Physisches Bildraster" verwendet, da es bei den Begriffen "DPI" und "PPI" offenbar einige unterschiedliche Auffassungen gibt.

Ich habe z.B. 2 Monitore, von denen der eine eine hohe Auflösung (3840 x 1600) und ein feines Bildraster hat, und der andere eine geringere Auflösung (2560 x 1440) und ein gröberes Bildraster hat.

Die Unterschiede beim Bildraster führen dazu, dass wenn ich ein Fenster vom einen zum anderen Monitor verschiebe, dieses Fenster beim anderen Monitor mit dem gröberen Bildraster größer erscheint, weil ja die selbe Menge an darzustellenden Pixeln des Fensters bei einem gröberen physikalischen Bildraster mehr Platz benötigen und dieses logischerweise dann ja größer aussieht.

Dies ist besonders dann gut zu erkennen, wenn ich das Fenster so verschiebe, dass es mit der linken Hälfte auf dem einen und mit der rechten Hälfte auf dem anderen Monitor sichtbar ist.

Wie kann man nun dieses jeweilige Pixelraster, das ja in den Werbe-Aussagen der Monitor-Hersteller eine große Rolle spielt, programmiertechnisch erkennen? Ich habe folgenden Code versucht:

Delphi-Quellcode:

CodeSite.Send('Monitor 1', Screen.Monitors[0].PixelsPerInch);
CodeSite.Send('Monitor 2', Screen.Monitors[1].PixelsPerInch);

Beide ergeben jedoch den selben Wert: 120. Wie kann man also diesen physikalischen Wert per Code erhalten?

[KodeZwerg]

Lese das mal durch, löst es Dein Problem?

[Uwe Raabe]

Frage: Welches Betriebssystem verwendest du?

Falls es eine aktuelle Windows 10 Version ist, probier doch mal das angehängte Manifest für deine Anwendung zu verwenden. In Delphi 10.1 Berlin kannst du das in den Projektoptionen unter Anwendung - Manifestdatei einstellen.

[PeterPanino]

Ich fürchte, dass ich mich wieder mal falsch ausgedrückt habe. Ich habe aber wirklich das gemeint, was ich in der Überschrift geschrieben habe:

Wie kann ich das physische Pixelraster eines Monitors erfahren?

Ich möchte also NICHT meine App an irgendeine Auflösung anpassen, sondern ich habe wirklich nur das gemeint, was ich geschrieben habe.

[KodeZwerg]

Zitat:

Zitat von PeterPanino (Beitrag 1411864)

Wie kann ich das physische Pixelraster eines Monitors erfahren?

In Handbuch von Monitor-Dokumentation sollte es bei Technischen Details vermerkt sein.

[himitsu]

Vor allem bei neueren Windowsen kann für jeden Monitor einzeln die DPI/Zoom eingestellt werden
und seit Windows 10 geht es sogar dass die Fenster "optisch" gleich groß bleiben, selbst wenn sie zur Hälfte auf unterschiedlichen Monitoren liegen.

Und ältere Delphis haben noch nichts drin, um mit High-DPI umzugehen,
ABER...
* dort kümmert sich dann Windows um die Skalierung (hier bleibt für dich das Fenster gleich groß, aber Windows vergrößert/verkleinert "deine" Pixel)
* und in neuen Delphis kann/tut sich die VCL/FMX darum kümmern (malt mehr/weniger Pixel, anstatt die Pixel zu skalieren)


Wie schon der RAM in Virtual und Real getrennt ist und dazwischen ein Mapping existiert,
so gibt es das auch bei Displays Canvas. Aber die Meisten kennen das vor allem "nur" bei Druckern.
http://michael-puff.de/Programmierun...ts/Print.shtml
Oder eben die automatische Skalierung der "ganzen" Programmfenster anstatt deren Inhalt. (bei Programmen die sich nicht als HighDPI-komatibel ausgeben)




Das physikalische Raster bei LCD ist ja fest, steht auf der Verpackung und stimmt meistens mit der "maximalen" Auflösung überein.
(wobei viele Beamer gern mit FullHD werben ... im Eingang ... aber im Ausgang dann nichtmal HD bieten :wall:)

Vorteil ist hier auch, dass die Dimensionen bei LCD/OLED/... fest sind.
Bei Röhren konnt man das Bild nicht ganz bis zum "konkaven" Rand schieben, ohne die Ecken zu verlieren, weswegen dort das Bild nie die maximale Fläsche nutzen konnte,
und es dort mit den DPI auch praktisch unmöglich war, dass der PC diese automatisch erfahren konnte, weil es durch die Benutzer frei verschoben werden konnte und es sich über die Zeit auch wieder verschob.
Und natürlich auch noch der Overscan, also Pixel außerhalb des sichtbaren Bereichs, meist bei analogen Fenseh-Signalen auf digitale Displays.




Das physische Pixel-Raster alleine hat selten eine Aussagekraft:

Die physikalische Auflösung des Displays (wobei hier auch nochmal eine Skalierung im Display sein kann, wenn z.B. 800x600 auf einem 1920x1080 dargestellt werden)
die physische Auflösung der Grafikkarte (globale Skalierung im "Desktop" ... kennst aus den Monitoreinstellungen im Windows)
dann nochmal die Skalierung des Programms/Fensters
zusätzlich kannst du drinnen auch nochmal selber eine weitere Skalierungebene auf deinen Canvas legen
und ganz schlimm im FMX zu sehen, wo du verschachtelte Panels/Komponenten unterschiedlich TControl.Scaleieren kannst (also nicht der Canvas skalliert, sondern das, was darauf gemalt wird)

[Uwe Raabe]

Zitat:

Zitat von PeterPanino (Beitrag 1411864)

Ich möchte also NICHT meine App an irgendeine Auflösung anpassen, sondern ich habe wirklich nur das gemeint, was ich geschrieben habe.

Und ich habe dir ein Manifest geschickt, mit der deine Anwendung (zumindest unter einer aktuellen Windows-Version) diese Informationen in den von dir bereits abgefragten Werten für PixelsPerInch liefert.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1411870)

Zitat:

Zitat von PeterPanino (Beitrag 1411864)

Ich möchte also NICHT meine App an irgendeine Auflösung anpassen, sondern ich habe wirklich nur das gemeint, was ich geschrieben habe.

Und ich habe dir ein Manifest geschickt, mit der deine Anwendung (zumindest unter einer aktuellen Windows-Version) diese Informationen in den von dir bereits abgefragten Werten für PixelsPerInch liefert.

Wenn dein Programm nicht explizit als High-DPI-kompatibel gekennzeichnet ist, dann werden gewisse APIs "virtualisiert" und liefern dir in deinem Programm "andere" Werte,
entsprechend den Daten die Windows bei der Skalierung verwendet, wird dir da nur das interne/virtuelle Wert gegeben, welchen dein Programm eben nutzt, anstatt dem, was wirklich im System vorhanden ist.

Es ist praktisch das Gleiche wie bei den unterschiedlichen Verzeichnissen für 64 Bit und 32 Bit, wo dein Programm "hintenrum" auf andere Verzeichnisse umgelenkt wird, ohne dass es selber was davon mitbekommt. (außer es deaktiviert diese automatischen Umleitungen).

Und gerade für sowas gibt es eben dieses Manifest, wo dein Programm dem Windows seine "Fähigkeiten" mitteilt und Windows dann entsprechend andere Funktions-Versionen verwendet oder eben gewisse Dinge umleitet/virtualisiert.

[KodeZwerg]

@himitsu, wie schaut es mit DSR (Dynamic Super Resolution) aus?

[PeterPanino]

Der Hersteller meines größeren Monitors (LG ULTRAWIDE 38UC99) gibt bei "Pixel Pitch" einen Wert von "0,229 mm x 0,2299 mm" an, was auch rechnerisch hinkommt, wenn man die metrische Breite des Monitor-Bildes (870 mm) durch die höchstmögliche Auflösungsbreite des Monitors (3840 Pixel) dividiert:

870 mm / 3840 = 0,23 mm (annähernd)

Das sollten die Maße der einzelnen Hardware-"RGB Streifen" sein, also die physikalische Ausdehnung eines einzelnen Monitor-Bildpunktes, der einen roten, grünen und blauen Leuchtpunkt enthält.

Die metrischen Daten des Monitors habe ich übrigens aus dem EDID (Extended Display Identification Data) des Monitors ausgelesen.

[Der schöne Günther]

Wenn du schon die Größe deiner Bildfläche in mm auslesen kannst (ich kenne nur die Variante über GetDeviceCaps(..), wo ist dann eigentlich noch das Problem?