OT: Windows 7 und Bildschirme mit hohem Dotpitch - Erfahrungen
Ulrich Korndoerfer
Fï¿œr Interessierte hier eine Zusammenfassung meiner bisherigen
"Erlebnisse" / Erkenntnisse mit hohen Dotpitches unter einem
deutschsprachigem *64 bit* Windows 7.
*****
* Neue Variante: Windows 7 DPI-Skalierung
*****
Wie die frï¿œheren Versionen von Windows bietet auch Win 7 die
Mï¿œglichkeit, ï¿œber den Dialog "DPI-Einstellungen anpassen" dem System die
tatsï¿œchliche Pixeldichte des Monitors mitzuteilen.
Um den Dialog aufzurufen kann man zum Beispiel die Systemsteuerung
ï¿œffnen und zu
Systemsteuerung->Darstellung und Anpassung->Anzeige
navigieren. Dann in der linken Spalte "Benutzerdefinierte Textgrￜￜe
(DPI) festlegen" anklicken.
Im darauf erscheinendem Dialog "DPI-Einstellung anpassen" kann direkt
die Pixeldichte (in ppi) oder ein Skalierungsfaktor vorgegeben werden.
Der Skalierungsfaktor bezieht sich auf die von MS so genannte
Standardpixeldichte von 96 ppi. Fï¿œr einen Bildschirm mit zB 135 ppi (das
wï¿œre zB ein 11.6 Zoll Laptopbildschirm mit 1366*768 Pixeln) betrï¿œge der
Skalierungsfaktor dann ca. 1.41 bzw. 141%.
Im Gegensatz zu frï¿œheren Versionen von Windows (Ausnahme Vista) hat
dieser Dialog noch eine weitere Einstellmï¿œglichkeit: eine Checkbox
bietet an, die "DPI-Skalierung im Stil von Windows XP" zu "verwenden".
Per Default ist diese Einstellung abgewï¿œhlt.
ï¿œber diese Checkbox kann festgelegt werden, ob das System in die
Darstellung des GUIs von Applikationen eingreift oder nicht:
a) Checkbox angewï¿œhlt (DPI-Skalierung im Stil von Windows XP)
Das System greift nicht in die Darstellung ein. Einer Applikation werden
die real existierende Pixelanzahl und der in der Dialogbox gewï¿œhlte
DPI-Wert ï¿œbermittelt. Das ist das gleiche Verhalten wie unter frï¿œheren
Versionen von Windows (vor Vista).
Beispiel fï¿œr VB6 Applikation: Bildschirm 1366x768 Pixel, 135 DPI/PPI
Screen.Width -> 1366
Screen.Height -> 768
Screen.TwipsPerPixelX -> (1/135)/(1/1440) = 10.666...
Screen.TwipsPerPixelY -> (1/135)/(1/1440) = 10.666...
b) Checkbox nicht angewï¿œhlt (Windows 7 DPI-Skalierung)
Das System greift in die Darstellung ein. Einer Applikation wird ein
Bildschirm mit 96 dpi Auflï¿œsung und entsprechend reduzierter Pixelanzahl
vorgegaukelt.
Beispiel fï¿œr VB6 Applikation: Bildschirm 1366x768 Pixel, 135 DPI/PPI
Screen.Width -> 1366*(96/135) = 971
Screen.Height -> 768*(96/135) = 546
Screen.TwipsPerPixelX -> (1/96)/(1/1440) = 15
Screen.TwipsPerPixelY -> (1/96)/(1/1440) = 15
Fï¿œr die Applikation sieht es so aus, als ob sie auf einem Bildschirm mit
971x546 Pixeln bei einer Pixelauflï¿œsung von 96 DPI laufen wï¿œrde.
*****
* Wie wird die Windows 7 DPI-Skalierung realisiert
*****
Im Aero-Betrieb werden alle Bildschirmausgaben nicht mehr wie frï¿œher
direkt auf den Desktop gerendert, sondern in einen Memorybuffer. Danach
wird der Buffer auf den Desktop geblittet. Das bietet ua. folgende Vorteile:
- Der Memorybuffer kann im (meistens reichlich) vorhandenem
Videokartenram gehalten werden. Das Rendern kann die
Hardwarebeschleunigungsmethoden des Videochips verwenden.
- Der Buffer ist persistent im Videokartenram, und kann jederzeit
abgerufen werden
- Alle nï¿œtigen Arbeiten fï¿œr die Ausgabe auf den Schirm erfolgen nun
direkt im Videoram und kï¿œnnen vom Videochip durchgefï¿œhrt werden.
Vor allem der letzte Punkt bietet nun viele Mï¿œglichkeiten/Vorteile, da
nun die Hardwarevorteile des Videochips genutzt werden kï¿œnnen. Der
Buffer kann zum Beispiel vor der Ausgabe transformiert werden
(durchgefï¿œhrt ohne CPU-Belastung direkt in der/durch die Graphikkarte).
Dadurch ist es zB mï¿œglich, das GUI einer Applikation als "Textur" zu
behandeln und es zB auf einer der Seitenflï¿œchen eines rotierenden
Wï¿œrfels anzuzeigen.
Ebenso einfach ist es, den Buffer bei der Ausgabe zu skalieren
("StretchBlit"). Und genau das wird bei der DPI-Skalierung gemacht:
- die Applikation rendert ihre Fenster in einen maximal 971x546 groï¿œen
Buffer
- das System gibt den Buffer skaliert um den Faktor 135/96 (1.4065) auf
den Monitor aus
Positive Folgen:
- eine Applikation, die mit dem tatsï¿œchlichen DPI-Wert des Systems nicht
zurechtkommt (da sie intern nicht berￜcksichtigt, daￜ die Applikation
auch auf Schirmen laufen kï¿œnnte, die eine andere Auflï¿œsung als 96 dpi
haben), funktioniert nun problemlos. Im GUI wird nichts abgeschnitten,
alle Bedienungselemente sind sichtbar.
Negative Folgen:
- das GUI erscheint "verwaschen", da die Pixels um einen "krummen"
Faktor 1.4065 skaliert werden mï¿œssen
- die Mauskoordinaten mï¿œssen nun umgerechnet werden auf das
Koordinatensystem des Buffers, damit auch weiterhin zugeordnet werden
kann, wo zB tatsï¿œchlich hingeklickt wurde. Das kann auch mal schief
gehen (in Grenzfï¿œllen).
*****
* Welche Variante sollte gewï¿œhlt werden
*****
Meiner Meinung nach sollte die "Windows 7 DPI-Skalierung" gewï¿œhlt
werden, also die Checkbox "DPI-Skalierung im Stil von Windows XP
verwenden" abwï¿œhlen.
Dies ist eine globale Einstellung, die erst mal fï¿œr alle Anwendungen
gilt: fï¿œr *alle* Applikationen wird die Win7 DPI-Skalierung *eingeschaltet*.
Windows 7 erlaubt (zumindest theoretisch, zu den Einschrï¿œnkungen kommen
wir noch) es, diese DPI-Skalierung nun wieder *individuell* fï¿œr jede
einzelne Applikation *abzuschalten*:
- jede Applikation, die der Meinung ist, sie brï¿œuchte keine besonderen
Maï¿œnahmen auf Schirmen mit hohem DPI-Wert, kann dies dem System
mitteilen. Das System verwendet dann fï¿œr diese Applikation die Win7
DPI-Skalierung nicht.
Dazu muￜ sie entweder ein Manifest haben und in diesem Manifest per
<dpiAware>True>/dpiAware> dem System mitteilen, daￜ eine DPI-Skalierung
nicht stattfinden soll. Dies ist der von MS empfohlene Weg. Oder sie
kann das auch ï¿œber einen speziellen API-Call beim Programmstart tun.
Diese Mï¿œglichkeit wurde wohl unter Vista? eingefï¿œhrt, wird aber
inzwischen von MS als "deprecated" eingestuft.
- zusï¿œtzlich kann der Benutzer fï¿œr jede Applikation individuell ï¿œber den
Eigenschaftendialog der Applikation unter dem Reiter "Kompatibilitï¿œt" im
Bereich "Einstellungen" mit der Checkbox "Skalierung bei hohem DPI-Wert
deaktivieren" die Win 7 DPI-Skalierung fï¿œr diese Applikation abschalten.
Das Muster lautet also:
- DPI-Skalierung global einschalten
- Applikationen, die auf diese Problematik vorbereitet sind, kï¿œnnen
diese fï¿œr sich selbst abschalten, Benutzereingriff ist nicht
erforderlich. Das funktioniert immer (zumindest nach meinen bisherigen
Erfahrungen).
Ein Ratschlag fï¿œr eigene VB6-Applikationen, von denen man sicher ist,
daￜ sie auch unter hohen Auflￜsungen laufen: sie sollten ein Manifest
mit auf den Weg bekommen, falls sie auch unter Win7/Vista zum Einsatz
kommen sollen. Auch aus anderen Grï¿œnden fï¿œhrt der Weg an einem Manifest
fï¿œr VB6-Applikationen, die fï¿œr einen Einsatz unter Vista/7 in Frage
kommen sollen, nicht mehr vorbei. Mit einem Manifest kann/sollte zB auch
die Rechte/Privilegien-Verwaltung feingesteuert werden (Stichwort
UA-Control).
- Fï¿œr Applikationen, die zwar intrinsisch "dpi-aware" sind, dies aber
dem System nicht von sich aus mitteilen, kann per Benutzereingriff die
DPI-Skalierung abgeschaltet werden.
- Bei Applikationen, die Probleme bei der Darstellung auf Schirmen mit
hohem DPI-Wert haben, kann der Benutzer entscheiden, ob er mit den
Einschrï¿œnkungen leben kann und die DPI-Skalierung fï¿œr diese App
abschaltet oder aber die DPI-Skalierung gewￜhren lￜￜt. Das GUI erscheint
dann zwar verwaschen (und es gibt mï¿œglicherweise Probleme mit dem
Erfassen von Mauspositionen in Grenzfï¿œllen), aber immerhin gibt es nun
nicht mehr die typischen Probleme, die man mit Applikationen hat, welche
nicht auf hohe DPI-Werte vorbereitet sind.
*****
* Probleme
*****
Es wï¿œre nicht MS, wenn es nicht auch Probleme mit der Umsetzung oben
skizziertem Konzeptes gï¿œbe. Wie so oft bei MS: Konzeption hui, Umsetzung
pfui ;-) Vielleicht hilft ja das erste Servicepack weiter :-)
A) Programme, die per Manifest sich als DPI-Aware bezeichnen
Schï¿œn. Aber was, wenn das Programm dann doch Probleme macht? Hier wï¿œre
es hilfreich, daￜ man dann fￜr solche Programme trotzdem die
DPI-Skalierung *aktivieren* kï¿œnnte. Dazu habe ich aber bis jetzt noch
keine Mï¿œglichkeit gefunden. Ok, man kï¿œnnte versuchen, per Ressourcentool
in der eingebetteten Manifestdatei das dpi-aware flag zu entfernen. Habe
ich noch nicht probiert. Jedenfalls ein Weg, der fï¿œr den normalen
Benutzer nicht (so einfach) gangbar wï¿œre.
B) 64 Bit Programme
Das Verhalten, welches hier WIN7 an den Tag legt, verstehe ich ganz und
gar nicht. Es scheint so, als ob *generell* bei 64 Bit Programmen der
Bereich "Einstellungen" des Reiters "Kompatibilitï¿œt" des
Eigenschaften-Dialoges *nicht* zur Verfï¿œgung steht (ist deaktiviert).
Konsequenzen:
- Auf ein 64 Bit Programm, welches durchaus in der Lage ist, mit hohen
DPI-Auflï¿œsungen zurechtzukommen, dies aber nicht selbst dem System
meldet, wird stets die DPI-Skalierung angewendet. Man kann das nicht
ï¿œber den Eigenschaftendialog abschalten!
Was soll das? Bei 32 Bit Programmen geht das Abschalten "von Hand" doch
auch!
Beispiel bei mir ist das *Konfigurationsprogramm* FileMenuTools.exe
(nicht die Extension selber) fï¿œr die Shell-Kontextmenu-Erweiterung
FileMenuTools. Das ist ein 64 Bit-Programm, welches aller
Wahrscheinlichkeit nach keine Probleme mit hohen DPI-Werten hat. Das
eingebettete Manifest hat kein dpi-aware Flag. Konsequenterweise wird
die DPI-Skalierung angewendet. Ich kann sie nicht abschalten, weil der
entsprechende Punkt im Eigenschaftendialog der Applikation nicht zur
Verfï¿œgung steht!
Oder der alternative Explorer Q-Dir. Den gibt es in einer 32 Bit und in
einer 64 Bit Version. Beide haben eine eingebettetes Manifest ohne
dpi-aware flag. Bei der 32 Bit Version habe ich die DPI-Skalierung ï¿œber
den Eigenschaftendialog deaktiviert, das Programm lï¿œuft einwandfrei und
kommt mit der hohen DPI-Auflï¿œsung zurecht. Die 64 Bit Version lï¿œuft
immer mit der DPI-Skalierung, und ich kann sie nicht im
Eigenschaftendialog abschalten. Warum darf ich das bei einer 64 Bit App
nicht?
Nun kï¿œnnte man im speziellen Fall von Q-Dir sagen: ok, dann nimm halt
die 32 Bit Version und verzichte auf die 64 Bit Version. Da gibt es aber
noch ein kleines Problem:
Q-Dir verwendet/bindet ein die gleichen Shell-Kontextmenuerweiterungen,
die fï¿œr den Explorer installiert sind. Und hier tut sich ein weiteres
Problemfeld zumindest der 64 Bit-Version auf:
32 Bit Programme unter W7/64 laufen zwar bis jetzt (nach meiner
Erfahrung) problemlos. Verwendet das Programm aber eine
Shell-Erweiterung (COM-Server Dll, die in den Windows Explorer
eingebunden wird), ergeben sich folgende Konstellationen:
- reine 32 Bit Shell-Erweiterung
Lￜￜt sich installieren/registrieren, wird aber im WindowsExplorer nicht
verwendet, wahrscheinlich weil dieser per Default ein 64 Bit Prozess
ist. In Q-Dir 32 Bit sichtbar, in Q-Dir 64 Bit nicht.
- 7Zip 64 Bit Shell-Erweiterung
Die ist merkwï¿œrdig. Sichtbar in Explorer 64, Q-Dir 64 und Q-Dir 32!
- Andere 64 Bit Shell Erweiterungen
Sichtbar in Explorer 64, Q-Dir 64, nicht in Q-Dir 32!?
Bin noch am Knobeln, welche Systematik dahintersteckt. Sobald ich
nï¿œheres weiss, kï¿œnnte ich ja dazu hier einen weiteren Post folgen
lassen. Hat jemand Interesse?
C) 32 Bit Programme, die sich nicht per Manifest als DPI-Aware bezeichnen
Prinzipiell problemlos. Die DPI-Skalierung ist eingeschaltet (da global
gesetzt), nach Bedarf kann sie ï¿œber den Eigenschaftendialog der
Anwendung ausgeschaltet werden.
Aber:
Bei meinen anfￜnglichen Schritten mit W7/64 hatte ich den Eindruck, daￜ
es eine Rolle spielt, von welchem Ort aus ein Programm ausgefï¿œhrt wird:
A) C:\Programme Ordner oder Unterordner (fï¿œr 64 Bit Programme)
B) C:\Programme (x86) Ordner oder Unterordner (fï¿œr 32 Bit Programme)
C) Anderer Ort
Dabei schien es so zu sein, daￜ bei einem Programm, welches vom Ort A)
ausgefï¿œhrt wurde, es keine Rolle spielte, welche Einstellung fï¿œr die
DPI-Skalierung gewï¿œhlt wurde: sie war *immer* abgeschaltet.
Kann ich aber nicht mehr reproduzieren.
*****
* Fazit fï¿œr Applikationsentwickler
*****
Da man nicht weiￜ, was der User auf seinem System eingestellt hat, ob er
in der Lage ist, bei Bedarf die DPI-Skalierung abzuschalten und wegen
der Spielchen, die W7 treibt:
- Programm fï¿œr die Verwendung unter hohen DPI-Werten (also
auflï¿œsungsunabhï¿œngig) programmieren (diese EMpfehlung war auch schon fï¿œr
frï¿œhere Versionen von Windows richtig)
- Manifest mit dpi-aware flag einbetten!
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
Schmidt
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb im
Newsbeitrag news:OU%23B3$QbKHA...@TK2MSFTNGP04.phx.gbl...
Danke daf�r - wird hier "sogleich archiviert"... :-)
Werd demn�chst wohl auch meine erste Win7-
Test-Maschine aufsetzen.
Olaf
Ulrich Korndoerfer
Man kann also die DPI-Skalierung *global* ein bzw. ausschalten.
Applikationsbezogen kann man die DPI-Skalierung *individuell* ausschalten.
Damit ist man wohl besser bedient, die DPI-Skalierung global
einzuschalten, da nur dann es mï¿œglich ist, fï¿œr eine Applikation
*individuell* die DPI-Skalierung nach Wunsch ein- oder ausschalten zu
kï¿œnnen.
Schaltet man die DPI-Skalierung *global* aus, kann man sie leider nicht
fï¿œr Applikationen, die dies nï¿œtig hï¿œtten, *individuell* einschalten.
Besser wï¿œre es, man kï¿œnnte fï¿œr jede Applikation *individuell* die
DPI-Skalierung *einschalten*. Dann kï¿œnnte man die DPI-Skalierung
*global* abschalten. In den meisten Fï¿œllen dï¿œrfte dies heutzutge
ausriechen. Fï¿œr die noch verbleibenden Ausnahmen (schlecht programmierte
Applikationen) kï¿œnnte man dann diese *individuell* einschalten.
So, wie das MS zur Zeit gelï¿œst hat, ist man gezwungen, die
DPI-Skalierung *global* einzuschalten, damit man dann *individuell* fï¿œr
jede Applikation entscheiden kann, ob man die DPI-Skalierung haben oder
nicht haben mￜchte. Der Nachteil dabei ist, daￜ nun fￜr fast jede "alte"
Applikation nach der Installation noch zusï¿œtzlich der Benutzer den
Aufwand hat, die DPI-Skalierung abschalten zu mï¿œssen.
Wï¿œre es mï¿œglich, per Applikation *individuell* die DPI-Skalierung
unabhï¿œngig von der globalen Einstellung ein oder ausschalten zu kï¿œnnen,
kï¿œnnte man global die DPI-Skalierung ausschalten. Bei den allermeisten
Applikationen mￜￜte dann der Benutzer nach der Installation des
Programmes nichts mehr tun. Nur in wenigen Fï¿œllen wï¿œrde er dann die
DPI-Skalierung *einschalten*.
Harald M. Genauck
> Fï¿œr Interessierte hier eine Zusammenfassung meiner bisherigen
> "Erlebnisse" / Erkenntnisse mit hohen Dotpitches unter einem
> deutschsprachigem *64 bit* Windows 7.
> ...
Sehr, sehr interessant - danke schï¿œn fï¿œr Deine Mï¿œhe.
Hiermit
http://www.microsoft.com/downloads/details.aspx?familyid=24da89e9-b581-47b0-b45e-492dd6da2971
kann man so einiges in Sachen Kompatibilitï¿œt anstellen. Das hat mir
schon bei einigen Uralt-Tools und -Apps gut geholfen (bisher
allerdings nur unter Vista-/Win7-32Bit) ...
In Sachen "DPI-Einstellung" habe ich es allerdings nicht ausprobiert.
Ich habe das Problem der ï¿œberlangen Lable-Texte & Co. "ein fï¿œr alle
Mal" durch eine systemweite Font-Substitution "gelï¿œst" - die alten
MS-Pixel-Fonts durch den TrueType-Font Segoe UI ersetzt.
Mï¿œglicherweise lieï¿œe sich anwendungsspezifisch der Fix "HighDpiAware",
auch unter W64, nutzen?
Viele Grￜￜe
Harald M. Genauck
"ABOUT Visual Basic" - http://www.aboutvb.de (Hrsg. + Redaktion)
"VISUAL STUDIO one" - http://www.visualstudio1.de (Chefredakteur)
Ulrich Korndoerfer
Harald M. Genauck schrieb:
> ...
> In Sachen "DPI-Einstellung" habe ich es allerdings nicht ausprobiert.
> Ich habe das Problem der ï¿œberlangen Lable-Texte & Co. "ein fï¿œr alle Mal"
> durch eine systemweite Font-Substitution "gelï¿œst" - die alten
> MS-Pixel-Fonts durch den TrueType-Font Segoe UI ersetzt.
>
Hm, bei hohen DPI-Settings kann es ja auch zu einer Reihe anderer
Probleme kommen. ZB typischer Fall:
- CommandButton ist fest auf eine bestimmte Breite in Pixeln festgelegt,
das Programm kï¿œmmert sich nicht um die aktuelle Schirmauflï¿œsung
Lï¿œuft das Programm nun auf einem Schirm mit hohem DPI Wert, passiert
folgendes:
- Der Button wird schmï¿œler (gleiche Pixelanzahl, weniger Zentimeter).
- Wurde ein Bitmapfont fï¿œr die Beschriftung verwendet, bleibt die
Beschriftung weiterhin lesbar, da ja die Textausgabe in Pixeln weiterhin
die gleiche Breite hat.
- Wurde ein skalierbarer Font verwendet (TrueType, OpenType und
Genossen), ￜndert sich nun die Anzahl der Pixel (wird grￜￜer) bei
gleicher Fontgrￜￜenangabe (in Points), und im Ergebnis kann es
passieren, daￜ die Beschriftung nicht mehr vollstￜndig sichtbar wird.
Besonders schlimm wird das bei Beschriftungen, die mit einem kurzen Wort
beginnen, gefolgt von einem langen Wort. Bei zB
"DPI Einstellungsï¿œnderungsdialog"
als Beschriftung wï¿œrde der zweite Teil sehr wahrscheinlich komplett vom
Button verschwinden (es sei denn der Button wï¿œre sehr hoch) und der
Benutzer mￜￜte ￜber die Bedeutung der noch sichtbaren Beschriftung "DPI"
rï¿œtseln. Dieses Beispiel ist ï¿œbrigens eines, wo die Verwendung von
Nicht-Bitmapfonts als schnelle Lï¿œsung fï¿œr die DPI-Problematik eher
kontraproduktiv wï¿œre.
Am Rande: wie macht man denn eine systemweite Fontsubsitution? Meinst Du
damit, daￜ auf dem System des Benutzers, auf dem die Applikation laufen
soll, das System so verￜndert wird, daￜ zB aus Anforderungen fￜr "MS
Serif" still und leise auf einen anderen Font umgeschaltet wird?
> Mï¿œglicherweise lieï¿œe sich anwendungsspezifisch der Fix "HighDpiAware",
> auch unter W64, nutzen?
>
Verstehe ich jetzt nicht ganz. Falls Du damit meinen solltest, fï¿œr ein
64 Bit App, fï¿œr die das System die DPI-Skalierung verwendet, dies
abzuschalten, indem man an dessen Manifest rumschraubt: wahrscheinlich
mï¿œglich.
Es ist halt nicht so ohne, am Manifest rumzuschrauben:
- Manifest ist eingebettet
Hier mￜￜte die Resource Manifest erst entfernt werden, dann extern
geï¿œndert (DPI-Aware Flag hinzufï¿œgen) und das Manifest wieder als
Resource hinzugefï¿œgt werden. Direkt das eingebettete Manifest in der EXE
zu ï¿œndern (zB mit einem Hexeditor) geht nicht.
- Manifest ist nicht eingebettet
Das wï¿œre schon einfacher, da hier es wahrscheinlich reichen wï¿œrde,
direkt die Manifestdatei zu ï¿œndern.
Mï¿œglicherweise gibt es noch einen dritten Weg (fï¿œr Exes mit
eingebettetem Manifest):
- Zusï¿œtzlich eine externe Manifestdatei erstellen, die das DPI-aware
Flag setzt.
Das hatte ich schon mal probiert, allerdings ohne Erfolg. Mï¿œgliche
Ursachen, warums nicht geklappt hat:
- meine externe Manifestdatei war nicht korrekt. Das Format der
Manifestdateien ist komplex und die Dokumentation eher spï¿œrlich.
- externe Manifestdateien werden ignoriert, wenn die Exe bereits ein
eingebettetes Manifest hat. Das wï¿œrde ja Sinn machen, denn ohne ein
solches Verhalten kï¿œnnte man relativ leicht "von aussen" das Verhalten
einer Exe manipulieren.