Welche Monitor-Parameter sind die richtigen für meinen Mac?

[[Mitglied Diwa…]]

4K? 5K? Wer einen Mac hat, hat’s schwerer, einen passenden Monitor zu finden. 4K ist in aller Munde, hat toll viele Pixel und ist mit bezahlbaren guten IPS-Panels von jedem Hersteller am Markt vertreten. Ob 4K für den Mac jedoch das richtige ist und warum auch ein teurer 4K-Monitor kein wirklich gutes Bild liefern kann, zeigt jenes Video wunderbar. Obacht, es geht um trockene Technik.

 

 

[[Mitglied Phoi…]]

Seit wann optimiert Apple nur noch für zwei PPI? Wenn ich mich recht erinnere, sehen die UI-Guidelines vor, Icons von 16x16 bis 1024x1024 vorrätig zu halten.

Aber netter Trick, den walled garden hübscher zu machen, indem man die native Auflösung kaputtskaliert, bevor es an die Graphik ausgeliefert wird, falls die Behauptungen des Narrators wahr sind.

@Narrator: Emily Young als dumm zu bezeichnen, ist reichlich polemisch -- und ein ziemlich Brett von einer Firma mit ca. 15000 Abonennten (Jaja, Milliarden Fliegen fressen scheisse, doch sind mir Firmen mit, pff, fünfzehn bis zwanzig Millionen Abonnenten vertrauenswürdiger als Panegyrik des Narrators). Ich hab mir das nicht zu Ende angeschaut, weil mir der Narrator schlicht auf den Sack geht, wenn er ständig rumflennt, dass Apple nur 110 und 220 ppi könnte und alles, was nicht daraufhin nativ vorliegt, sähe scheisse aus. Beim Vorspulen noch kurz das Fiasko mit der Skalierung mitbekommen und dann unter Schrott verbucht.

[[Mitglied Diwa…]]

vor 10 Minuten schrieb Phoibos:

Ich hab mir das nicht zu Ende angeschaut,

Hättest du tun sollen, lohnt sich.

Eine mehr oder weniger Zusammenfassung ist hier zu finden:

https://bjango.com/articles/macexternaldisplays2/

 

Daraus ein erhellendes Diagramm (das auch im Video vorkommt):

bearbeitet Juli 26, 2023 von Diwarnai

[[Mitglied Phoi…]]

vor 37 Minuten schrieb Diwarnai:

erhellendes Diagramm

Für die Illumination bin ich nicht Mac-User genug. 

[[Mitglied Diwa…]]

Wenn es dich eh nicht betrifft, hör einfach auf, den thread kaputtzumachen.

[[Mitglied Phoi…]]

vor 14 Minuten schrieb Diwarnai:

den thread kaputtzumachen.

Sachliche Fehler und Kritik an Marketinggeschwurbel ist kein „kaputtmachen“. Naja, vielleicht doch für Gläubige. 

 

vor 42 Minuten schrieb Diwarnai:

Wenn es dich eh nicht betrifft

Es hat mich mal betroffen beim Vorgänger. Wir haben uns nach einer Testphase mit mehreren HighDPI-Displays (wie Retina anderswo genannt wird) gegen die von Apple entschieden, Dell und Eizo machten das Rennen. Den Händler wunderte das nicht, als er die Monitore wieder abholte, 

Und natürlich betrifft der Vorwurf, Apple könne nicht skaliere (bzw. generiert auf der Softwareebene eine spezifische native Auflösung), jeden Apple-Nutzer. 

Was ist eigentlich, wenn 4k auf einem 17“-Display gerendert werden? Das wäre ja auch Retina…

Kurz: das Video verkürzt und informiert sachlich falsch: Ein Punkt, der auf das Doppelte skaliert wird, braucht vier mal so viele Pixel. 
 

Aber vielleicht bin ich auch der Idiot, dessen Weisheit Torheit vor Apples Genie ist. 

[Ralf Herrmann]

Das Video ist sehr gut. Man muss sich nur die Zeit nehmen. Es zieht sich anfangs etwas, liefert dann aber essentielles Wissen für den Mac-Monitor-Kauf. 

[[Mitglied Phoi…]]

vor 1 Stunde schrieb Ralf Herrmann:

essentielles Wissen

Für Apple-Apologeten vielleicht. Das treffendste Argument ist das "Platz-Argument". Aber das können zwei 4k-Displays noch besser lösen als ein 5k-Display. Und, sofern man nicht Apple kauft, wahrscheinlich sogar günstiger.


Gibt es einen anderen Beweis außerhalb des Videos für diese These:

? Im SDK stand dazu vor ein paar Jahren jedenfalls nicht, soweit ich es in Erinnerung hatte.

[[Mitglied Diwa…]]

Leider hast du nicht ansatzweise begriffen, um was es im Video geht. Wie auch …

vor 11 Stunden schrieb Phoibos:

Ich hab mir das nicht zu Ende angeschaut,

 

vor 40 Minuten schrieb Phoibos:

Gibt es einen anderen Beweis außerhalb des Videos für diese These:

Ich habe einen zweiten link weiter oben gepostet. 

Mit "Apple-Apologeten" haben weder das Video noch dieser thread zu tun. Ganz im Gegenteil, es werden die Einschränkungen durch das zu starre macOS-Design aufgezeigt.

[[Mitglied Seba…]]

Das Video ist absolut richtig – es geht kurz gesagt darum wie macOS die Größe seines UIs berechnet, wie das Bild dann gerastert wird, und wie es zum Monitorplanel gelangt.

 

Apple kann sein UI immer noch nicht stufenlos ("vektorbasiert") skalieren*, sondern skaliert es ausschließlich auf die beiden Darstellungsgrößen 1x oder 2x, bevor es dann das Bild rastert und auf den Monitor schickt, der bei Apple-Geräten IMMER 110 oder 220ppi haben muss(!), damit dann die dargstellte Größe (in Längenmaßen) dem entspricht, was Apple für richtig erachtet hat und die Pixel 1:1 von der Hardware abgebildet werden. Das hilft bei der Softwareentwicklung, weil sich Anwendungsentwickler praktisch nicht um PPI-Dichten, Abbildungsgrößen etc. kümmern müssen, es gibt defacto nur eine Abbildungsgröße, die normal oder doppelt so scharf dargestellt wird, fertig. Das war damals zur Einführung von "Retina" super, weil super einfach und sofort wirksam. Den langen Weg, andere Abbildungsgrößen und ppi-Auflösungen zu unterstützen, ist Apple dann nie gegangen, Windows wurde belächelt weil das da so ein Problem war, bis es jetzt viele Jahre später halt in der Praxis kein Problem mehr ist.

 

Andere Skalierungsgrößen des UI werden im System zwar angeboten, dann ist es aber so dass macOS intern eine höhere (oder worst-case niedrigere) Auflösung rastert, und dann das erzeugte Bild hinterher(!) interpoliert. Apple zeigt sogar eine Warnung an wenn man das macht – die Darstellungsqualität und Performance leide darunter, weil ja interpoliert und danach von macOS repariert wird, was halt mäßig gut geht (Textdetails, Flimmern bei Bewegung, Unregelmäßigkeiten in regelmäßigen Mustern, ...**, was für Grafiker und Animationsdesigner eigentlich unbrauchbar ist). Das selbe passiert natürlich (und ist altbekannt und nichts macOS-spezifisches) wenn man in den erweiterten Einstellungen eine andere Pixelzahl als Ausgabegröße festlegt als die native Pixelzahl des Displaypanels.

 

Andere Skalierungsgrößen möchte man immer dann haben, wenn der eigene Monitor nicht genau 110 oder 220ppi hat (das haben kaum welche***) – weil darauf sonst das UI viel zu groß oder viel zu klein dargestellt wird, oder wenn man halt selbst mit gutem Visus oder anderem Sehabstand die Präferenz hat mehr Inhalt zu sehen, oder mit schlechtem Visus lieber alles größer dargstellt hätte. Würde macOS vor dem Rastern die UI-Beschreibung skalieren (wie Windows seit 10, und soweit ich weiß auch die gängigen Linux-UIs), dann wäre das gerasterte Bild immer in der nativen Auflösung des Monitors und könnte ohne Skalierung seitens macOS, Grafikkartentreiber oder Monitor 1:1 ausgegeben werden. So wird das Bild erst größer gerastert und danach skaliert.

 

Apple umschifft das ganze nach wie vor, in dem jedes Displaypanel das eine neue physische Größe hat, auch eine neue "krumme" (ungewohnte) Pixelzahl in Länge x Breite erhält (z.b. ein mbPro mit 3072 x 1920 Pixel), um letztlich wieder auf 220ppi zu kommen (in iOS gibt es auch noch einen 3x-Modus für 330ppi).  Nur zwei Laptops wurden mal tatsächlich so konfiguriert ausgeliefert, dass sie eine interpolierte Abbildungsgröße ausgegeben haben, mit den entsprechenden Effekten (ein altes Air, und das erste Macbook Pro mit dieser Touchleiste – 2019?), weil die Display-Panels nicht 110/22oppi hatten – letztlich braucht Apple da ja einen Lieferanten der das aus 220ppi-Rohlingen so auf Maß schneidet dass es passt, und manchmal ist das halt vermutlich auch für Apple schwierig.

 

Lange Rede, kurzer Sinn

– man kann in macOS sein UI nicht auf was anderes als 1x oder 2x skalieren ohne Bildqualität einzubüßen, weil Apple rastert bevor es skaliert.

– das heißt für alle Bildschirme die nicht 110 oder 220ppi haben, dass entweder die Abbildungsgröße "falsch", oder die Darstellung nicht sauber ist.
– es gibt kaum Monitore die 220ppi haben, die üblichen 4k-27"-Geräte kommen auf 165ppi, was genau da ist wo es bei macos am meisten schmerzt, weil Faktor 1,5.

 

 

 

* früher kurz mal eine Zeit lang in einer Beta, bevor das wieder entfernt wurde: https://news.ycombinator.com/item?id=29066484

** https://bjango.com/articles/macexternaldisplays2/
 

*** es gibt am Markt wenige Bildschirme mit 220ppi, die nicht von Apple selbst sind: LG ultrafine 5K (mit dem imac-27"-5k-Panel drin, LG ist dessen Lieferant), Samsung Viewfinity S9, Dell Ultrasharp U3224.

 

Mehr:
https://en.wikipedia.org/wiki/Resolution_independence#macOS

https://discussions.apple.com/thread/7989573

https://forums.macrumors.com/threads/default-vs-scaled-resolution-performance.2322741/

 

bearbeitet Juli 27, 2023 von Sebastian Nagel

[[Mitglied Phoi…]]

vor 10 Minuten schrieb Diwarnai:

Wie auch …

Naja, 40 Minuten habe ich ja geschafft... Aber den Typen kann ich nicht am Stück gucken...

 

vor 11 Minuten schrieb Diwarnai:

die Einschränkungen durch das zu starre macOS-Design aufgezeigt.

Das ist doch schon mal eine ganz andere Message 😉

vor 23 Minuten schrieb Diwarnai:

Ich habe einen zweiten link weiter oben gepostet.

Der zweite Link ist die Quelle für den ersten Link...

Aber Du hast Recht, die Lösung findet sich bei 42'22"...

 

vor 5 Minuten schrieb Sebastian Nagel:

Das Video ist absolut richtig

Danke für die verständlichere Erläuterung.

vor 18 Minuten schrieb Sebastian Nagel:

er bei Apple-Geräten IMMER 110 oder 220ppi haben muss(!)

War nicht die Rede von 218ppi des Studiodisplays?

 

vor 7 Minuten schrieb Sebastian Nagel:

man kann in macOS sein UI nicht auf was anderes als 1x oder 2x skalieren ohne Bildqualität einzubüßen, weil Apple rastert bevor es skaliert

Eine Möglichkeit bleibt, die Auflösung zu verändern. Wir hatten ja je zwei Display verschiedener Hersteller zur "Anprobe" und da mein Mann quasi blind war, hat er mit seinem User auf dem Display (er hat das korrekte Teilungsverhältnis ausgerechnet, ich nenne jetzt nur Zahlen) 1280x1024 bei x2 Skalierung verwendet. Ich verwendete jeweils die native Auflösung (Visus 1,2). Natürlich bin ich nicht sensibel genug, um die Moire zu erkennen, wovon berichtet wird, aber ich kann mir Use-Cases vorstellen, in denen das eine Rolle spielt.

Der Punkt der Ergonomie bleibt, da nicht nur für Apples Retina der Abstand Display-Auge eine Rolle spielt (vgl. Retina und ppi auf einem iPhone oder iPad mit dem Retina für Desktop/Laptop-Klassen).

 

 

[[Mitglied Seba…]]

Für Grafiker heißt diese Skalierung in der Praxis:

 

Wenn ich viel mit Vektormustern oder Schrift arbeite, habe ich  das Problem, dass meine grafischen Rhythmen nicht nur ungünstig auf die Hardwarepixel des Monitors fallen können (was lästig genug ist, aber mit hiDPI/Retina-Displays weniger schlimm wird) sondern ungünstig auf die virtuelle Auflösung in der macOS mein Bild rastert, und dann nochmal ungünstig auf die Hardwarepixel des Monitors. Zweifache  Frequenzüberlagerung --> Unregelmäßigkeiten ohne Ende.

 

Wenn ich mit Bewegung arbeite (oder einfach nur scrolle), und wird beim Skalieren je nach Position des Inhalts relativ zur Interpolation mal so mal so interpoliert, und ich sehe ein "Schimmern".  Das wird hier sehr gut dargestellt: https://bjango.com/articles/macexternaldisplays2/

 

Bei Bildbearbeitung, Video etc., ist die Interpolation relativ egal, das sieht tatsächlich kein Mensch.

bearbeitet Juli 27, 2023 von Sebastian Nagel

[[Mitglied Seba…]]

vor 4 Minuten schrieb Phoibos:

Danke für die verständlichere Erläuterung.

War nicht die Rede von 218ppi des Studiodisplays?

ja, die 220 sind "relativ", manchmal sind es 218, manchmal 225 ... dabei ist dann halt tatsächlich die Abbildungsgröße unterschiedlich und ein 1cm hoher Button ist etwas kleiner oder größer – allerdings halt in einem Bereich wo es in der Praxis egal ist, auf jeden Fall ist es noch "richtig genug".

Das hat damit zu tun, dass Apple halt dann doch noch einigermaßen computer-sinnvolle Pixel-Dimensionen einsetzen will und nicht vollkommen krumme Werte. 

 

Bei den neuesten Macbook Pros sind es übrigens ca. 250ppi, was für Apple-Verhältnisse eine wilde Abweichung ist – da ist dann die Abbildungsgröße tatsächlich deutlich kleiner, was für ein Pro-Gerät und bei näherem Sehabstand ja durchaus Sinn ergibt. Ich hatte ja zu dem Zeitpunkt gehofft, dass macOS tatsächliche Auflösungsunabhängigkeit spendiert bekommen hat, ist aber nach wie vor nicht der Fall).

 

vor 4 Minuten schrieb Phoibos:

Eine Möglichkeit bleibt, die Auflösung zu verändern. Wir hatten ja je zwei Display verschiedener Hersteller zur "Anprobe" und da mein Mann quasi blind war, hat er mit seinem User auf dem Display (er hat das korrekte Teilungsverhältnis ausgerechnet, ich nenne jetzt nur Zahlen) 1280x1024 bei x2 Skalierung verwendet.

Das ist richtig, diesen "Trick" gibt es – wenn man eine Abbildungsgröße findet die einem passt und die ein Ganzzahlverhältnis ergibt, kann man über die erweiterten Einstellungen zur Bildschirmauflösung (nicht UI-Skalierung!) etwas erwirken, das scharf und richtig groß aussieht.  Wir verwenden das, um einen 4k-Fernseher mit einem mac-mini im Präsentationsraum anzusteuern. Der hat weder 110 noch 220ppi, aber die Abbildungsgröße von UI-Elementen ist uns da defacto egal, weil wir eh immer im Vollbild was darstellen und nicht darauf arbeiten.

[[Mitglied Seba…]]

so jetzt hatte ich Zeit das Video noch ganz durchzusehen (bei Tempo 2x geht's so halbwegs ... anstrengende Typen), und ich kann den Begriff  " Apple-Apologeten" schon ein wenig nachvollziehen – die tun ja tatsächlich so als könnte man daran gar nichts ändern, und die Hersteller die 4k-Panels auf 27" (also 165ppi) anbieten seien auf dem Holzweg.

 

Das Grundproblem ist aber schon, dass Apple damals als sie Retina eingeführt haben den unproblematischen Weg der Pixel-Verdoppelung gegangen sind, wodurch sich niemand um Abbildungsgrößen kümmern musste – alle modernen Anwendungen waren doppelt so scharf, alle Uralt-Anwendungen waren halt pixelig wie ehedem. Super Lösung um sowas auf einen Schlag überzeugend einzuführen – it just works.

Dann haben sie sich halt ausgeruht, statt im nächsten Schritt ihre UI-Bibliothek so anzupassen, dass UI-Element-Größen in relativen %-Anteilen der Bildschirmfläche statt in Pixeln / 2x2-Pixeln definiert werden müssen / können. Für die Software-Entwickler wäre das eine Umstellung gewesen, aber natürlich für Apple durchdrückbar, wie jeder andere Bibliotheks- und Plattformwechsel den sie machen auch.  Für den User hätte es freie Display-Wahl und freie Anpassbarkeit zwischen mehr Platz und größere Darstellung bedeutet – da aber externe Displays recht lange für Apple gar keine Priorität waren und der LG 5K die Mac-Pro-Leute abgedeckt hat wo Geld ohnehin keine Rolle spielt, war das halt kein Thema – es waren ja alle offiziellen Displays immer auf 220ppi und somit kompatibel. Nur beim MacMini hat man das Thema akut wahrgenommen, war aber offenbar egal genug.

 

Windows hatte die Möglichkeit nie, indirekt zu beeinflussen, welches Display verwendet wird, da musste MS immer schon den schweren Weg beschreiten und das UI tatsächlich auflösungsunabhängig machen.

Das war lange Zeit großer Murks (weil nicht einfach), klappt aber seit Windows 10 bestens, egal welches Display dran hängt (in meinem Notebook z.B. ein 320ppi-Display, neben dem ein MBpro mit seinen 220ppi richtig grob aussieht). Das Bild wird immer 1:1 in der nativen Auflösung gerastert – und unabhängig davon kann ich das UI in 1%-Schritten genau so skalieren wie es mir passt, das hat mit der Pixeldichte des Displays schlichtweg nichts mehr zu tun. Das ist auch kein Performance-Problem, da keine riesigen Bilder 60x pro Sekunde skaliert und repariert werden müssen. Fast schon erstaunlich: auch ein Verschieben eines UI-Elements auf ein Hilfsdisplay mit anderer Pixel-Dichte funktioniert inzwischen nahtlos, d.h. die Größe bleibt gleich, nur die Schärfe nimmt ab.

(uralte GDI-Anwendungen und DirectX-Spiele können über die tatsächliche Auflösung des Displays getäuscht werden, damit ihre internen UI-Kalkulationen die von all dem nichts wissen nicht zerbrechen – braucht man aber zunehmend nicht mehr).

 

Schön wäre, wenn Apple zumindest mal einen 3x3-Modus einführt, für 330ppi-Displays (z.B. 8k auf 27", oder eben ein macbook Pro mit 4k-Display) – das wäre zum einen Highend, zukunftsweisend wie damals "Retina", und den Preisen angemessen, zum anderen könnte man über eine Halbierung davon auch einen 1,5x-Modus erwirken, der weniger schlimme Rundungsfehler erzeugen würde als irgendwas ganz krummes, und "zufällig" (also rein mathematisch) auch die 165ppi von 4k auf 27" treffen würde und so auf einen Schlag die große Masse an Displays dieser Qualität kompatibel machen würde.

Ganz schön wäre es natürlich, wenn Apple seine Hausaufgaben erledigen und ein auflösungsunabhängiges UI bringen würde ... vielleicht nach in der Version nach Ventura

 

Zurück zum Video: Die stark vereinfachte Aussage, 5k sei auf Apple schon wesentlich besser als 4k (richtig müsste es heißen 220ppi sei besser als 165ppi, das ganze gilt sonst ja nur für 27"-Dispays), ist absolut gesehen richtig – aber nicht weil 165ppi so extrem viel schlechter ist als 22oppi, sondern weil Apple das zusätzlich nochmal durch die Interpolation vermiest. Genauso vermiesen sie es aber für eigentlich viel bessere 32"-8k-Displays (was natürlich kostentechnisch ein Randgruppenproblem ist) ... da wird dann nämlich wieder nur für 220ppi gerastert und danach auf die real vorhandenen 275ppi hochskaliert – nur bei einem 8k-40"-Monster würde es wieder nativ passen, aber das will niemand vor sich stehen haben.

[[Mitglied Phoi…]]

@Sebastian Nagel Vielen Dank nochmals, dass Du Dir die Zeit genommen hast, mir das im Video präsentierte zu erklären.

vor 16 Stunden schrieb Sebastian Nagel:

ein auflösungsunabhängiges UI

Sollte Quartz das nicht können, da es auf NextSteps Postscript-Renderpfad aufgesetzt? Ich hatte gedacht, dass der "Zwang", eine potente Graphikkarte zu haben*, darin begründet war.


*) Irgendein Update setzte, relativ unnötigerweise, eine bestimmte CPU-Generation als Minimum vor, so dass ein Haufen Macs, böse formuliert, Elektroschrott wurden. Microsoft machte mit Windows 11 ja ähnliches.

[[Mitglied Seba…]]

vor 11 Minuten schrieb Phoibos:

@Sebastian Nagel Sollte Quartz das nicht können, da es auf NextSteps Postscript-Renderpfad aufgesetzt? Ich hatte gedacht, dass der "Zwang", eine potente Graphikkarte zu haben*, darin begründet war.

Ich zitiere mal von hier: https://news.ycombinator.com/item?id=29066484

 

I worked on the Cocoa frameworks back when the hope was arbitrary scaling. The short answer to your question is "rounding." At 1.5x, a box of length 3 occupies 4.5 physical pixels. Either one side of the box will be blurry, or the box must get resized to align with physical pixels, which can cause mis-centering of text or icons, or unexpected clipping or truncation. There was also a lot of custom layout code in existing apps, both first and third party, which just didn't work at arbitrary scale factors because it was never tested.

Yet another complication is that apps are expected to handle scale changes, e.g. if the user drags a window from one display to another. Android doesn't have to deal with this.

After years of trying to make it work, Apple basically gave up and did the scaling in WindowServer.

 

Also ja, theoretisch sollte es, aber "frei skalieren", nur weil was Vektoren sind, ist halt nur die halbe Arbeit – am Ende muss die Größe und Position das auf Ganzzahlen (Pixel) quantisiert werden wenn man ganz scharfe Ergebnisse will – das muss das SDK, mit dem das UI definiert wird, halt können und man will es vielleicht als UI-Entwickler beeinflussen können, und es braucht ein Rechenmodell das die Elemente dann entsprechend in allen denkbaren Konstellationen (Zoomstufen, Größen, Positionen) so umpositioniert und verformt, dass ein Ganzzahl-Ergebnis raus kommt.

Oder man lebt mit der Unschärfe die sich durch Nicht-Ganzzahlen-Treffer ergeben (die bei Displays jenseits 200ppi nicht mehr so *wirklich* ein Riesenproblem wäre, der Worst-Case ist ja, dass 2 Pixel zu 50% aktiviert werden – nicht super, aber vielleicht auch nicht das große No-Go wenn das mit dem Korrigieren nicht klappt).

(Siehe Font-Raster-Aliasing-Hinting-Thema nebenan – grundlegend selbes Problem, nur vielleicht andere Präferenzen für eine der möglichen Lösungen)

 

Es kommt halt immer darauf an, wie Größen von Elementen in Anwendungen deklariert werden können ... Prozente der Bildschirmfläche / des Eltern-Elements, virtuelle Pixel, echte Pixel, ... Das ist die Basis dafür, dass ein Renderer hinterher saubere Pixel in jeder Größe ausspucken kann. Wenn das nicht gegeben ist, wird es immer nachträglicher Murks bleiben. Ich weiß nicht ob Apple im SDK da einen Ansatz hat und der Teil des Problems "gelöst" ist, dann wäre es "nur noch" ein besserer Rasterer der mal kommen müsste.