Beiträge von wwelti

Hallo SpaceGuard,

Danke für die präzisen Angaben.

Die Ruckler passieren in einem regelmäßigen Intervall, richtig? (z.B. alle 2.5 Sekunden ein Ruckler)

Alles spricht dafür, daß Dein Monitor eine feste interne Panel-Update-Frequenz hat. D.h, das Updaten des Panels ist nicht synchron mit der Bildfolge, die von der Grafikkarte geliefert wird.

Leider scheint dieses Phänomen recht verbreitet zu sein (d.h. viele TFT-Modelle haben eine fixe interne Panel-Update-Frequenz), doch viele User bemerken es nicht bzw. stören sich nicht daran. (Oder können das Problem nicht einordnen...) Deshalb gibt es zu den meisten Monitoren auch keine Informationen, ob sie das Problem haben oder nicht. (Da hilft nur Testen mit PixPerAn o.ä. )

Man kann das Problem deutlich entschärfen (allerdings nicht vollständig aufheben), indem man die Vertikalfrequenz mithilfe eines Tools (z.B. PowerStrip) sehr genau an die interne Update-Frequenz des Monitors angleicht. Denn das Tearing tritt immer genau dann auf, wenn es eine "Überholung" des Update-Prozesses gibt. D.h. wenn der Unterschied zwischen den zwei Frequenzen bei 0.5 Hz liegt, gibt es genau einen Ruckler (oft verbunden mit kurz aufblitzendem Tearing) alle zwei Sekunden.

Dieses Angleichen ist recht knifflig (erfordert einige Geduld), aber einige User haben es schon gemacht. Der Lohn der Mühe ist, daß die Frequenz der Ruckler (inkl. Tearing) sehr stark reduziert wird, z.B. nur noch ein Ruckler alle 20 Minuten.

In diesem Thread wurde das Thema schon eingehend besprochen (Da sind auch weiterführende Links, auch über das Angleichen der Frequenzen):

Viele Grüße
Wilfried

Hallo hiTCH-HiKER,

Schön zu wissen Es stimmt schon, eine Linux-Version wär' eigentlich zeitgemäß.
Es wäre wohl auch nicht unbedingt ein Riesenproblem das Programm zu portieren, aber ich habe im Moment einfach nicht die Zeit dafür, sorry.

Die Windows-Version war einfach wichtiger (in welchem Laden läuft schon Linux? Und 99.9% aller Zocker haben Windows installiert), ich hoffe ihr habt dafür Verständnis.

Weiterhin wäre die Linux-Version wohl nicht ganz so einfach und problemlos zu verwenden wie die Windows-Version; die Modularität von Linux ist eben sowohl Segen als auch Fluch. Einfacher macht sie es dem unbedarften Anwender leider nicht gerade.

Falls jemand von Euch einen Linux-Schlierentest programmieren sollte, wird Prad ihn sicher gerne hosten!

Edit: Hat eigentlich mal jemand probiert ob es unter Wine läuft? Ok... ich sollt' es eigentlich selber mal testen; irgendwie komm' ich einfach nicht dazu...

Viele Grüße
Wilfried

Hallo Zarathustra,

Zitat

Aber da steht 16,70 Millionen Farben, wenn das jetzt noch auf 16,2 korrigiert wird, ist die Frage nach der Farbtiefe geklärt - 16,2 bedeutet 18bit, 16,7 bedeutet 24bit...

Einspruch!
2^18 = 262144 Farben bei 18 Bit Displays
2^24 = 16777216 Farben bei 24 Bit Displays (also 16.7 Millionen).

Ich schätze die 16.2 sind einfach ein Tippfehler.

Edit: Ups... Einspruch widerrufen!

Man (also Ich) sollte doch den kompletten Thread lesen bevor man postet. Tatsächlich. Mit Dithering kommt man auf eher ungefähr 16.2 Millionen! Faszinierend. Das macht man sich sonst gar nicht so klar...

Viele Grüße
Wilfried

Hallo j.kraemer,

Ich tippe mal das ist beim Erstellen des Screenshots passiert. Sonst müsste er eigentlich mehr als nur 5 verlorene Frames haben.

Ich möchte betonen daß es eigentlich nicht Sinn der Sache ist, Screenshots vom Schlierentestprogramm zu machen... Die Schlieren kann man so jedenfalls nicht "knipsen" ;). Und die ermittelten Werte landen sowieso in der Ergebnis-Datei.

Viele Grüße
Wilfried

Hallo Aichi,

Sorry: Das ist kein Ergebnis.

Gesehen hast Du die Schlieren, richtig? (Soweit ist auch alles ganz einfach)
Aber Schlieren zu "messen", bzw. vergleichbare Werte oder Aussagen über Schlieren zu ermitteln, ist leider ganz und gar nicht einfach. Darum ist auch das Programm nicht einfach.

Bevor wir hier in dem Thread eine lange Diskussion anfangen:
Es gibt hier einen Schlierentest-Bereich im Forum. Da wird alles über Schlieren und was damit zu tun hat diskutiert.

Viele Grüße
Wilfried

Hallo thiemo,

Nur ganz knapp (ich muß gerade schnell weg):

Es kann sein daß Deine Karte schon bleibende Überhitzungsschäden hat. Ganz am Anfang hattest Du die Probleme ja noch nicht!

Und ja, Überhitzung kann genau zu den beschriebenen Problemen führen!

Viele Grüße
Wilfried

Hallo thiemo,

Genau kann ich Dir nicht sagen, was Dein Problem ist. Aber eins ist sicher: Am Monitor liegt es nicht!

Nach Deiner Beschreibung vermute ich eher ein Hardware-Problem als ein Software-Problem.

Deine Beschreibung erinnert sehr an Beschreibungen von übertakteten Grafikkarten. Komplett-PC's wie von Medion sind oftmals besch...eiden zusammengestellt. Es ist (meiner Erfahrung nach) leider eher die Regel als die Ausnahme, daß man mit billigen Komplett-PC's Probleme hat.

Wird die Grafikkarte im Betrieb sehr warm? Vielleicht ist der PC unzureichend gekühlt? Funktioniert der Lüfter der Grafikkarte noch? (Möglicherweise ist die Karte auch schon gar gebraten... )

Vielleicht stimmt die Spannungsversorgung nicht? Schau mal was genau auf dem Netzteil draufsteht, und sag mal welche Komponenten in Deinem PC drin sind (alle). Allerdings führt so etwas normalerweise eher zu Systemabstürzen; es ist eher selten daß nur die Grafikkarte "verhungert".

Edit: Last not least: Natürlich könnte auch einfach nur die Grafikkarte hinüber sein.

Viele Grüße
Wilfried

Hallo SpaceGuard,

Es handelt sich definitiv um Tearing.

Die häufigste Ursache dafür ist, daß vSync deaktiviert ist. Ja, ich habe gelesen daß bei Dir das Problem auch bei vertikaler Synchronisation besteht. Es gibt jedoch häufig mehrere Einstellungen für vSync (oftmals eine für OpenGL und eine für Direct3D). Es ist sogar bei einigen Treiberversionen so, daß die Einstellung für Direct3D nicht gezeigt wird. Bist Du sicher, daß Du die Einstellung für das Spiele-API, welches Du verwendest (also OpenGL oder Direct3D), auf vSync=on eingestellt ist?

Die zweite Möglichkeit ist, daß Dein Monitor ein internes Synchronisationsproblem hat. Dann musst Du die Vertikalfrequenz anders einstellen. In diesem Falle sollte das Tearing allerdings nicht allzu deutlich sein; außerdem ruckelt es dann dauernd recht spürbar.

Vielleicht kann ich Dir mehr zu Deinem Problem sagen, wenn Du mal folgendes probierst:

Starte PixPerAn (gibt's im Testprogramme-Unterforum hier im Board), und öffne das Flacker-Testbild.
- Welchen Wert zeigt die "fps" Anzeige rechts oben an?
- Bleibt der "frames Lost" Wert stabil, oder ändert er sich ohne zutun? (Er sollte sich nur beim Wechsel zwischen verschiedenen Sektionen des Programmes ändern)
- Und vor allem: Siehst Du im Flacker-Testbild irgendwelche horizontalen Linien? Wenn ja: Bewegen sie sich irgendwie? Oder blitzen sie in regelmäßigen Zeitabständen kurz auf?
Edit: - Im Startscreen ist ein fahrendes Auto zu sehen. Ist die Bewegung des Autos gleichmäßig, oder gibt es regelmäßige "Hüpfer" oder Ruckler in der Bewegung?

(P.S. Wenn es an der vSync-Einstellung liegt, wirst Du in PixPerAn keine horizontalen Linien auffinden können, da PixPerAn automatisch synchronisiert)

Viele Grüße
Wilfried

Hallo zusammen,

thop: Danke für die Info mit der Parhelia. Die verwendet tatsächlich bis zu 10 Bit pro Farbkanal. (Nennt sich GigaColor, wohl weil man so 2^30, also etwas mehr als eine Milliarde verschiedener Farben darstellen kann) Das war mir bis jetzt entgangen. Ich habe mich mal gleich ein bißchen darüber informiert.

Nun ist es so, daß das standardmäßige Win-API auf dem Desktop nur 8 Bit pro Farbkanal unterstützt. Hier werden auch im 32 Bit Modus nur 8 Bit pro Farbkanal verwendet, auch mit der Parhelia. Es gibt allerdings ein spezielles Photoshop-Plugin, welches anscheinend erlaubt, Adobe Photoshop in Verbindung mit der Parhelia mit echten 10 Bit pro Farbkanal zu verwenden.

Weiterhin scheint ab DirectX 8.1 eine Unterstützung von 10 Bit pro Farbkanal in Texturen zu existieren. Außerdem wird in Spielen ja sehr viel in Echtzeit berechnet (Beleuchtung usw), so daß auch bei normalen Texturen ein sichtbarer Qualitätsvorteil bleibt. Für Spiele ist dieses Feature also tatsächlich gewinnbringend.

Bei der DVD Wiedergabe wird auch vieles direkt auf der Grafikkarte gemacht, d.h. auch hier läßt sich das Standard-Win-API umgehen, so daß die 10 Bit pro Farbkanal durchgehend verwendet werden können. Eine höhere Qualität ist hier tatsächlich zu erwarten. (Die MPEG2-komprimierten Daten begrenzen an sich nicht die Farbtiefe des Materials, d.h. eine hohe Farbtiefe auf dem Ausgabegerät bringt deutlich schönere Farbübergänge)

Weiterhin profitiert sogar das standardmäßige Desktop ein wenig davon; jedenfalls dann, wenn eine softwaremäßige Farbkorrektur vorgenommen wird. Denn die von Windows verwendete Farbkorrektur-Tabelle erlaubt 16 Bit pro Farbkanal. D.h. die Qualität der softwaremäßigen Farbkorrektur wird besser. (das soll jetzt nicht heißen, daß durch eine Korrektur die Gesamtqualität der Desktop-Grafik besser würde; nur die Qualität der Korrektur an sich ist besser)

Wobei ich anmerken muß: Der auf vielen Monitoren übliche Gammafaktor von ca. 2.3 ist auf dem Desktop durchaus angenehm und bedarf in den meisten Fällen keiner weiteren Korrektur. Und Helligkeit und Kontrast kann man normalerweise auch direkt am Monitor regeln. D.h. wenn keine Korrektur notwendig ist, werden die "normalen" Desktop-Anwendungen definitiv nicht von den 10-bittigen Farbkanälen profitieren können.

Insgesamt gesehen hat hier der CRT in Verbindung mit einer solchen Grafikkarte für Profi-Grafiker tatsächlich einen echten Vorteil gegenüber dem TFT. Denn DVI unterstützt nur 8 Bit pro Farbkanal. (Wenn es da ein neueres, erweitertes Protokoll gibt, wird es zumindest von den meisten TFT's nicht unterstützt)

@Karras: Leider kann ich Dir nicht sagen, welche TFT's echte 24 Bit darstellen. Ich weiß nur daß meiner (Viewsonic VP201m) es nicht tut. (ist für mich allerdings nicht so schlimm, normalerweise fällt es (mir) auch nicht auf. Ich bin halt kein Grafiker...)

Viele Grüße
Wilfried

Hallo zusammen,

Ich persönlich kenne keine Grafikkarte, die bei 32 Bit mehr Farben darstellt als bei 24 Bit. Normalerweise werden von den 32 Bit 8 Bit einfach "verschenkt". 32 Bit werden also nur aus Performance-Gründen verwendet, da der Zugriff auf 32-Bit Datenworte wesentlich effizienter ist, als z.B: drei einzelne Bytes (für 24 Bit) zu schreiben.

Natürlich gibt es Grafikverarbeitungsprogramme, die Bilder intern im CMYK-Farbmodell verarbeiten, und dafür tatsächlich echte 32 Bit pro Pixel (oder sogar mehr) verwenden. Das kann aber so nicht direkt von der Grafikkarte angezeigt werden, d.h. bei der Anzeige wird das Bild grundsätzlich "on the fly" in eine RGB-Darstellung umgewandelt. Die volle Farbpracht gibt's also erst beim Drucken.

Ein CRT kann selbstverständlich "beliebig viele" Farben anzeigen, soll heißen: Er wird analog gespeist und beläßt die Helligkeitsinforamtionen durchgehend analog. Es kommt vielleicht noch ein bisschen Verstärkungsrauschen dazu, aber normalerweise ist das nicht wahrnehmbar.

Eine Grafikkarte die mehr als 8 Bit pro Farbkanal darstellen kann ist mir jedoch nicht bekannt (das müsste schon ein sehr spezielles Modell sein...) Somit sehe ich speziell hier keinen echten Vorteil von CRT's gegenüber einem guten TFT.

(Man muß dazu sagen daß nicht wenige TFT's keine echten 24 Bit anzeigen können, diese verwenden oftmals Dithering damit Farbverläufe nicht gar zu stufig wirken.)

Viele Grüße
Wilfried

Hallo crappo,

Ein wenig mehr Information wäre nicht schlecht. Wir können auch nicht hellsehen

- Wie hoch waren die Frame-Raten vorher?
- Hast Du den alten Monitor noch, so daß Du direkt vergleichen kannst?
- Hast Du außer dem Monitorwechsel irgend etwas anderes geändert? Irgendwelche Software installiert? (neue Graka-Treiber, Monitor-"Treiber", usw?)
- Wie ermittelst Du die Frame-Rate? (FPS-Anzeige des jeweiligen Spieles? Oder ruckelt es einfach stark, trotz hoher FPS-Anzeige?)

Hast Du möglicherweise irgendwelche Treiber-Einstellungen geändert? Ich würde ja auf Antialiasing tippen, aber ich glaube das kann die GF3 TI200 gar nicht, oder?

Edit: Nachtrag:... die GF3 TI200 kann doch Antialiasing. Ich muß da vorhin etwas verwechselt haben. Wenn AA aktiviert ist, wäre dies eine Erklärung für die niedrigen Frame-Raten.

Viele Grüße
Wilfried

Hallo Zaratustra,

Ja, ist die "neuste" Version. Bin in letzter Zeit nicht dazu gekommen, an der Version 2 weiterzuarbeiten... Sollte es eine neue Version geben, werde ich das sowieso in diesem Thread (siehe Topic) bekanntgeben.

Ob der Verkäufer das Testen mit dem Programm erlaubt, hängt wohl ganz vom Verkäufer ab ;)... ich habe da schon die unterschiedlichsten Erfahrungen gemacht. Ich würde es allerdings vormittags versuchen, wenn nicht so viel los ist.

Viele Grüße
Wilfried

Hallo VVVV,

Bitte lies doch nochmal das erste Posting in diesem Thread

Den S&H-Effekt gibt's auf allen TFT's. Auch eine Reaktionszeit von 0 ms würde nichts daran ändern. Die Unschärfe des S&H-Effektes entsteht erst im menschlichen Auge, nicht auf dem Bildschirm!

Die S&H-Schlieren werden meist als reine Bewegungsunschärfe empfunden.

Das "Flackern" wäre bloß eine (theoretische) Möglichkeit, den S&H-Effekt loszuwerden. (Bei CRT's gibts den S&H-Effekt genau darum nicht, weil jeder Pixel pro Vertikalzyklus nur einmal kurz aufblitzt, statt seine Helligkeit gleichmäßig zu halten)

Die Kombination aus Flackern und 85 Hz Vertikalfrequenz wäre eine in absehbarer Zeit technisch realisierbare Möglichkeit, einen TFT zu bauen, der die Tugenden eines CRT und eines TFT vereint. (sprich: Ergonomie sowie uneingeschränkte Spieletauglichkeit) Die 85 Hz Vertikalfrequenz habe ich deshalb vorgeschlagen, weil bei einer niedrigeren Frequenz das Flackern zu deutlich sichtbar wird (wie beim CRT halt).

Die besondere Schwierigkeit bei diesem Ansatz sehe ich darin, daß das Panel extrem schnell sein müsste. Denn außer den S&H-Schlieren gibt es ja noch die "normalen" (trägheitsbedingten) Schlieren. Bei einer Vertikalfrequenz von 85 Hz dürfte die _maximale_ (also in der ungünstigsten Farbkombination) Reaktionszeit des Monitors höchstens 11.7 / 11.7 (rise/fall) (somit gesamt: 23.4) ms betragen, damit die normalen Schlieren bei dieser Vertikalfrequenz nicht sichtbar werden.

Die allgemein üblichen Reaktionszeit-Angaben beziehen sich normalerweise auf den Schwarz->Weiß->Schwarz Übergangszyklus. Dies ist leider meistens eher der unkritischste Farbübergang, d.h. z.B. bei Grautönen sind die Reaktionszeiten meistens deutlich höher. Aus diesem Grund sind die Herstellerangaben für die Reaktionszeit oftmals nicht sehr aussagekräftig.

So gibt es m.E. heutztage kein TFT-Panel, daß meine oben beschriebenen Forderungen (11.7/11.7 im ungünstigsten Farbübergang) auch nur annähernd schafft.

Viele Grüße
Wilfried

Hallo Honig,

Wolltest Du sagen: Wenn Du in PixPerAn Shift-F7 drückst, wird in der Anzeige oben rechts eine Frame Rate von mehr als 300 fps angezeigt?

(Bitte versuche die Beschreibungen etwas eindeutiger zu formulieren )

Wenn pro Ruckler die "Frames lost" Anzeige um eins hochgezählt wird, bedeutet das, daß auf Deinem Rechner irgendetwas im Hintergrund läuft und gelegentlich für einen kurzen "Hänger" sorgt. Der Monitor hat daran keine Schuld.

(Natürlich besteht die Möglichkeit, daß beide Fälle gleichzeitig zutreffen, d.h. Du solltest die Ursache für das Ruckeln beseitigen und dann nochmals testen)

Bei TFT's sind die Kriterien für die Auswahl der Vertikalfrequenz anders als beim CRT. Da TFT's grundsätzlich flackerfrei sind (bzw. sein sollten), ist eine Vertikalfrequenz von 60 Hz normalerweise ausreichend. Viele TFT's haben sogar eine interne, von der Vertikalfrequenz unabhängige, feste Update-Frequenz. Bei diesen TFT's ist es relativ sinnlos, eine höhere Vertikalfrequenz als diese interne Update-Frequenz zu wählen.

Meines Wissens nach hat der 1880 eine solche feste interne Panel-Update-Frequenz ungefähr bei 60 Hz. D.h. 75 oder gar 85 Hz bringen Dir gar nichts außer zusätzlichem Geruckel und Tearing; mehr Bilder pro Sekunde werden jedenfalls nicht angezeigt!

Viele Grüße
Wilfried

Hallo Honig,

Ändert sich der "Frames Lost" Wert während den Rucklern?

Hallo Honig,

Die "frames lost" Anzeige in PixPerAn sagt nichts über den Monitor aus (kann ja auch gar nicht sein); sie sagt bloß ob der PC "rund läuft" und eine durchgehend gleichmäßige Framerate hinbekommt. (Bei Menüseitenwechsel gehen allerdings trotzdem immer mal wieder Frames verloren, das ist normal)

Ein interner Bild-Aussetzer des Monitors äußert sich daran, daß ein kurzer Ruckler sichtbar wird, die "Frames lost" Anzeige in diesem Moment jedoch _nicht_ hochgezählt wird.

Wollte das nur nochmal klar herausstellen...

Edit: Daß der NEC 1880 eine fixe interne Panel-Update-Frequenz hat (und damit das genannte Problem hat) ist bekannt. Leider haben wir immer noch keine vernünftige Liste, welche TFT's dieses Problem haben und welche nicht, da einfach viel zuwenige User das Problem bemerken. Und von denen, die davon wissen, sind nicht wenige der Meinung daß man dieses Problem nicht zu ernst nehmen sollte (und daß es auf keinen Fall Kaufentscheidend sein sollte) (meine eigene Meinung dazu behalte ich lieber für mich).

(Edit2: Es spielen ja auch nicht wenige User mit vSync=off, so daß man sowieso solche Sprünge hat, egal wie gut der Monitor ist. Viele User stört ein wenig Geruckel und Tearing also offenbar nicht besonders)

Viele Grüße
Wilfried

Hallo VVVV,

Sorry daß ich jetzt erst antworte ... aber wenn Du nur Dein Posting editierst bekomme ich das nicht unbedingt mit

Es natürlich vorbildlich von Dir, nicht zuviele Einzel-Messages erzeugen zu wollen. Aber als Antwort auf ein Posting eines anderen Pradlers ist editieren nicht unbedingt geeignet

Danke für den Link. Hmm... Ich bin eigentlich ziemlich sicher daß sich der gute Mann vertippt hat. Er hat 20 Hz gemeint, nicht 200, jede Wette!

Ich persönlich würde das natürlich nicht so als allgemeingültig stehen lassen. Naja, ich habe ja schon meine Ansicht zu dem Thema erklärt

Hmm, das mit dem Verschieben muß ich mir noch überlegen... Ich glaube ich mache einfach demnächst mal einen neuen Thread zu dem Thema in dem ich es am Anfang nochmal ganz ausführlich erkläre

Edit: Nur nochmal zur Erinnerung an alle: Der Titel dieses Threads war eigentlich: "Was bewirkt/beeinflusst Schlieren". Wenn es noch mehr Fragen zum Thema Flüssige Frame-Rate gibt, bitte einen neuen Thread öffnen.
Edit2: Direkte Followups auf hier gemachte Aussagen könnt ihr natürlich trotzdem hier posten... Hmmm ich hätte es wohl doch verschieben sollen... aber ich zerreiße nun mal nicht gerne Threads.

Viele Grüße
Wilfried

Hallo Rico,

Tja, ich schätze ich muß hier kapitulieren... Das ist halt so eine Windows Krankheit, daß viele Dinge nie vernünftig festgelegt wurden; hier z.B. das präzise Verhalten von DirectX-Aufrufen. Ich weiß nicht wie ich das Timing der DirectX-Aufrufe so hinbekommen kann daß die Messung funktioniert egal wie viel der Treiber puffert.

Ich könnte natürlich auf eine modernere DirectX-Version umsteigen; aber das ist mir jetzt zu blöd. Außerdem müssen sich dann die User unter Umständen DirectX nachinstallieren; ich wollte eigentlich daß das auch auf älteren Kisten nicht nötig ist.

Zumindest wird außer der CPU-Anzeige wohl alles funktionieren.

Viele Grüße
Wilfried

Hallo Rico,

Ich hab mal was im Programm geändert. Du kannst es ja mal probieren. Ich mache mir allerdings nicht allzu große Hoffnungen, daß es hilft...

Viele Grüße
Wilfried