Update-snelheid LCD

[Adion]

Een active matrix lcd, zoals de meeste schermen die je tegenwoordig tegenkomt worden als ik het goed begrijp pixel per pixel bijgewerkt, waarbij de andere pixels hun waarde behouden.
Een typische lcd kan op die manier alle pixels 60x per seconde bijwerken.

De vraag die ik nu heb en waar ik nog geen antwoord op heb kunnen vinden is hoe snel dit bijwerken gebeurd.
Ik heb het nergens expliciet kunnen vinden, maar het lijkt erop dat dit tegen ongeveer dezelfde snelheid gebeurd als de invoer word aangeleverd (bij hdmi of andere digitale input)
Vermits er normaal niet meer bandbreedte gebruikt word dan nodig neem ik aan dat dit echter tegen dezelfde snelheid gebeurd als de aanvoer van de beelden.
(1 beeld versturen duurt dus ongeveer 1/60ste van een seconde)

Als dit alles klopt zou echter de laatste pixel 1/60ste van een seconde later bijgewerkt worden dan de eerste.
(In dat geval lijkt het relatief hard op een crt denk ik, waarbij het beeld ook tegen ongeveer deze snelheid gescanned word)

Wat ik niet snap is waarom er dan geen tearing-verschijnselen optreden.
Je hebt dan namelijk steeds een deel van het beeld afkomstig van frame 1, en een deel dat al afkomstig is van de volgende frame.
Toch lijkt dit niet voor te komen (zolang de input gesynchronizeerd is met de refresh-rate van het display).
Ik vraag me dus af waar mijn fout zit of hoe dit dan precies in zijn werk gaat.

[alexandersamson]

Volgens mij wordt een LCD gelatched. Dus pas als alle pixels ready zijn, worden deze geupdate (gaat zo snel, is niet te volgen met je ogen of te zien als tear). Een CRT werkt met scanlines en dat is ook wel snel maar iets langzamer en wordt niet gelatched. Dat kan fysiek ook niet, want een cathode straalbuis kan geen miljoen beeldpunten bufferen en tegelijk weergeven, dat vereist ook een miljoen straalbuizen...
Tear bij LCD's wordt veroorzaakt door een off-sync tussen videokaart refresh en lcd refresh. Als je videokaart bijvoorbeeld met 100FPS output heeft en je LCD maar 75FPS aankan, dan kan je situaties krijgen dat er een gedeelte frame van je videokaart nog later pas op je beeldscherm komt. Je hebt dan een stuk oud frame en een stuk nieuw frame boven elkaar.
Daarvoor hebben ze double buffering uitgevonden en VSYNC. Met double buffering en vsync wordt het frame dat de videokaart wil sturen eerst in een extra buffer opgeslagen en pas gestuurd naar de monitor als deze een puls geeft dat deze is refreshed. Zo krijgt de monitor steeds een vol, nieuw frame. Nadeel van vsync is wel dat als de refreshrate van je beeldscherm hoger is dan die van je videokaart, dat hij maar op de helft van je monitorrefresh gaat lopen. In het geval van de 75FPS monitor dus op 37,5FPS. Dat komt omdat de monitor wacht op een vol frame elk frame, maar omdat de monitor sneller is dan de videokaart, is er geen vol frame in de buffer, dus slaat hij een frame over.
Zie het als dat Jan steeds 10 appels uit de mand wil pakken en als er te weinig liggen dat hij na een minuut weer terug komt. Elke minuut worden er 7 appels in de mand gelegd, tot een maximum van 10. Jan heeft dan precies elke 2 minuten 10 appels.
Die extreme drop in framerate kan weer worden opgelost met triplebuffering, maar dat gaat mijn pet te boven
Dus het aan/uit gaan van de pixels kan je inderdaad niet zien als tear. Deze worden dus gelatched, eerst allemaal geschreven in een buffertje, daarna allemaal vrijwel tegelijk weergegeven.
Tear wordt veroorzaakt door 2 (of meer) gedeeltelijke frames die op het zelfde beeld terecht komen.

Dat latchen kan je zien als een grote brede kooi waar allemaal hazewindhonden in kunnen. Je kent het wel dat hondenracen. Stel je hebt een batterij van kooien waar 10 van die honden in kunnen. Het kost je tijd om elk hokje te vullen met een hond, je moet een hond halen, in het hokje stoppen en hokje sluiten. Je hebt 10 seconden nodig per hond. Als alle hokjes open staan, rent de eerste hond die je in zijn hokje stopt gelijk de baan op als je nummer 2 haalt. Een toeschouwer ziet elke 10 seconden een hond de baan dus oprennen.
Met latching gebeurt het volgende: Alle honden worden in hun hokje gestopt, maar de hokjes blijven dicht. Totdat de laatste hond in zijn hokje zit. Dan krijgen alle hokjes tegelijk een signaal om open te gaan. Alle honden rennen nu tegelijk naar buiten, de baan op!
Zo werkt het ook met die pixels. Alle pixels worden in een tijdelijke buffer opgeslagen en op het moment dat de laatste pixel in het buffer zit: gaat de klep open en worden alle pixels tegelijk naar het scherm geschreven.

[ Voor 22% gewijzigd door alexandersamson op 30-12-2013 01:42 ]

[Adion]

Bedankt voor je reactie, maar het is nog steeds niet helemaal duidelijk hoe snel 'onmiddelijk' is, en hoe dat precies in zijn werk gaat of waar die buffers dan precies zitten.

De datasheet van 1 lcd die ik gevonden heb ( http://www.rockbox.org/wi...MR500Info/LS037V7DW01.pdf ) geeft alleen maar info over de digitale aansturing, en die snelheid is exact zo dat het 1 frame duurt om 1 frame te versturen.
Ik vind echter niet welke onderdelen er na de aansturing nog komen om de pixels uiteindelijk op het scherm te krijgen.

Wat ik tot nog toe gevonden heb is dat voor het laden van de condensator in elke pixel een analoog signaal gebruikt lijkt te worden, dat gegenereerd word door een DAC. Het lijkt er op dat een LCD driver meerdere (tot enkele honderden) DAC's kan bevatten, maar dat er nog steeds minder DAC's zijn dan het aantal pixels.

Een LCD-driver is dus de component die uiteindelijk aan de pixels aangesloten zit? Zijn er zo meerdere? Wat is de naam van het tussenliggende component dat de data buffered van de input en vervolgens aan de driver(s) doorgeeft?
http://www.intechopen.com/download/get/type/pdfs/id/11273

[alexandersamson]

Een klokpuls duurt volgens de datasheet ongeveer grofweg 40-160 nanoseconden. Gemiddeld iets van 100 om het makkelijk te houden.
de hele periode voor de HSYNC en de VSYNC lijken maximaal bij volle VGA resulotie 648 klokpulsen te duren, oftewel gemiddeld 64800 nanoseconden gemiddeld. Als ik naar de timingsdiagrammen kijk, lijkt het alsof HSYNC en VSYNC tegelijkertijd worden uitgevoerd over 2 aparte lijnen.
Daar komt nog een aantal nanoseconden bij voor hold time en dergelijke per klok, dus misschien dat je aan de 100000 nanoseconden komt per refresh cycle. Dat is 0.1 Milliseconden, oftewel 1 /10.000ste seconde heeft hij nodig om van pixel 1 tot pixel 'laatste' te verversen. Digitaal gezien dan. Helaas kunnen LCD's niet zo snel refreshen dus doet hij dit volgens de datasheet elke 57x een keertje (VSYNC refresh). Elke 17,5 milliseconden heb je een compleet nieuw beeld voor je neus, wat slechts 0,1millisecs nodig had om op te bouwen. Mits de videokaart/aansturing ook zo snel is natuurlijk. Je zal dus nooit kunnen merken dat pixel 1 eerder wordt geupdate dan de laatste pixel. Dat het hele beeld 57 keer per seconde wordt verversd zou je als je goede snelle ogen hebt wel kunnen zien, maar bij film of anti-aliased objecten lijkt mij dat erg stug.
Waarom wordt het beeld niet sneller ververst vraag je je af? Omdat LCDs het niet zo goed trekken om te snel verversd te worden, dan ga je last krijgen van ghosting en aanverwante problemen. Zeker bij koudere temperaturen is dat wel eens een probleem.
Je hebt niet zoveel DAC's nodig omdat er via shifting meerdere buffers kunnen worden geschreven per DAC.
(je kan met 1 persoon meerdere hondenhokken van de renbaan vullen, het duurt alleen langer als je deze ene persoon veel hokken moet laten vullen, het is dan wel goedkoper)

[ Voor 12% gewijzigd door alexandersamson op 30-12-2013 15:11 ]

[Adion]

Ik lees de datasheet toch anders.
Een klokpuls bij vga-resolutie is 40 nanoseconden, dat zijn er 26000 per lijn, en dus 12441600 ns per beeld ongeveer. Dat zijn 12 milliseconden. Inclusief een aantal extra lijnen pause komt dat behoorlijk in de buurt van wat nodig is om 60 Hz refresh rate te halen.
Als dit de data is die rechtstreeks naar de lcd gaat is er dus helemaal geen tijd over, en word de laatste pixel wel degelijk 12 milliseconden later geupdate dan de eerste.

[Brahiewahiewa]

Ik denk dat het effect daarvan gemaskeerd wordt door de overige ruis.
En je moet eens wat afleveringen van BrainGames gaan kijken; over hoe je hersenen met dergelijke inconsistenties omgaan

[slopert]

Alles wat nu gezegd is, relatief belangrijk. Maar het belangrijkste is hoe snel de kristallen in een lcd kunnen veranderen van positie. Bij een snelheid van (gemiddeld) 1ms kunnen er 100 beelden per seconden weergeven worden. Dit wel met behulp van een overdrive techniek.

Als je nu neemt dat het beeld (gemiddeld) per seconde niet voor 100% veranderd, dan kan je de huidige 144Hz panelen maken.

Een ander item is de v-sync (h-synch doet er niet toe). Als die aanstaat, dan geeft de videokaart het beeld door op het moment dat het beeld nodig is, zelfs als het frame niet helemaal klaar is. Op dat moment krijg je tearing. Staat de v-sync uit, dan wordt het beeld door geven op het moment dat het frame klaar is. Is het frame nog niet klaar, dan zal de lcd het laatste hele frame laten zien. Je krijgt hierdoor geen tearing, maar je kan dus een frame missen. Je videokaart zal dus minimaal (en constant) het minimale frames uit moeten kunnen rekenen waarop de monitor ingesteld is.Anders loop je de kans op dubbele frames.

Een andere manier om tearing te voorkomen is black frame insertion. Hiermee doe je tussen de frames een volledig zwart beeld. Dit zie je niet, omdat je ogen te langzaam zijn. Dit werkt beter bij IPS dan TN. Maar dat gaat wat ver denk ik. Het verschil dat zodra er spanning op een TN, het beeld wit wordt (rust toestand) en bij IPS zwart.

[ Voor 0% gewijzigd door slopert op 05-01-2014 16:20 . Reden: kleine spelfoutjes. ]

[Adion]

Hoe de bron werkt, en wat hier gedaan word om tearing tegen te gaan met v-sync (je uitleg over v-sync is volgens mij net omgekeerd) snap ik.
Dat het signaal (in zowel analoge als digitale bronnen) word aangevoerd aan een snelheid net genoeg voor 1 frame snap ik ook, en dit is het signaal dat ook bij een typisch lcd-paneel lijkt aan te komen.

Het andere uiterste snap ik ook, ook hier is makkelijk informatie over te vinden (polarisatie, gebruik van sub-pixels, actieve matrix met transistor/condensator per sub-pixel)

Het toevoegen van een zwart beeld is volgens mij een relatief recente toevoeging, die eerder helpt bij het oplossen van de discontinuiteit van beweging dan dat het veel met tearing te maken heeft.
Hoe dan ook, tv's/monitors met een klassiek 60Hz scherm zonder deze techniek hadden ook geen last van tearing, dus dat is het probleem ook niet.

Dat je hersens dit opvangen geloof ik niet erg. Bij goedkopere webcams/telefooncamera's is tearing duidelijk een probleem bij beweging, net omdat de pixels worden uitgelezen tegen een snelheid waarbij de laatste pixels eigenlijk al een frame voor zitten op de eerste pixels.

Waar ik dus maar moeilijk iets kan over vinden is hoe de aansturing van de individuele sub-pixels gebeurd nadat/tijdens een beeld word ontvangen.
De datasheet die ik hierboven linkte lijkt een aantal hints te geven doordat er gesuggereerd word dat er meerdere dac's tegelijk aan het werk zijn, en dat er voor een typische lcd meerdere van deze modules gebruikt worden.
Gecombineerd zou dit betekenen dat grote aantallen pixels gelijktijdig geupdate kunnen worden, wat zou verklaren waarom tearing niet optreed.
Ik zou het echter interessant vinden om hier een schema van te zien, en iets meer informatie te hebben over de concrete werking en tijd die het updaten in beslag neemt.

[slopert]

Het v-sync verhaal klopt. De meeste games zetten het ook dan ook uit.

Je hersens zien een film in de bioscoop ook maar met 24/25 fps perseconde, dat is dan al vloeiend.

Ik kan cq mag je geen schema's laten zien. Maar bedenk je dat de aansturende elektronica op MHz snelheid kan lopen als het nodig is, dat dat geen probleem zou hoeven zijn. er is immers maar een buffer nodig van 1 frame. De zwakste schakel is het straagste onderdeel van het hele gebeuren. In dit geval dus het draaien van de kristallen in de LCD.

Goedkope webcams halen maar 24 frames, dus dat je tearing daar ziet is heel begrijpelijk. Wij doen 720p conferencing met Azie heb een echt conferencing systeem en daat zien we geen tearing. Mar dat heeft dus te maken dat het systeem geoptimaiseerd is voor die ene taak en verder niks kan, in tegenstelling tot een generl purpose pc. Die dus lles kan, maar dan minder effficient.

Je hoeft geen schema te zien. Het zijn biffers en aanstuur buffers. Die kan je zo snel laten lopen als je er energie in wil steken. Voor het vergelijk, optische electronica is er ook, maar door de kosten zijn ze niet algemeen beschikbaar voor ons. Het punt is dat de kristallen van positie moeten wisselen, om licht door te laten of niet. Dat zal nu en in de toekomst de beperkende factor blijven voor deze techniek.

Over een jaar of 6 (geen gok, werderom geen bron) gaat de OLED productie omhoog en zal het een serieuse concurent voor de LCD worden. Niet dat ik geloof dat het DE techniek van de toekomst is, maar omdat oa Samsung er dik in gaat investeren. (lees meer winst).

[Adion]

V-Sync staat voor vertical sync, als het aan staat word de refresh rate dus gesynchronizeerd, zodat steeds een volledig beeld naar de lcd gestuurd word.
Als er niet gesynchronizeerd word kan het dus zijn dat er halverwege het vullen van de framebuffer geupdate word.
(In je eerste bericht zei je dat net bij het aan staan van v-sync een half beeld zou kunnen voorkomen, maar dat bedoelde ik dus met dat het net omgekeerd is, ook andere bronnen die ik vind bevestigen dit, zoals http://www.webopedia.com/TERM/V/Vsync.html )

Bij videoconferencing zal tearing zoiezo moeilijk opvallen vermits het beeld typisch slechts beperkt veranderd. Vooral bij pan-bewegingen zal het opvallen.

[alexandersamson]

Daarom heb je dus triple buffering, zodat vsync goed beide kanten op werken kan:
-als videoaanbod sneller is dan schermrefresh
-als videoaanbod langzamer is dan schermrefresh.

hoe het precies werkt weet ik niet, maar ik weet wel dat het zo werkt
zonder triple buffering heeft vsync alleen effect bij een videokaart die sneller is dan het beeldscherm, anders is het een killer voor je framerate.
Tearing bij LCD kan alleen (voor mensenogen zichtbaar zijn) als je buffers zo langzaam zijn dat je het kan zien (Oftewel je hebt een zeer gierig goedkoop chinees apparaat wat slecht aansuurt, die buffers zijn normaal echt supersnel), of als het videoaanbod geteard wordt aangeleverd. Dan is je signaal off-sync bijvoorbeeld. Zelfs dan gaat het voor mij ook ingewikkeld worden

[Adion]

Oud topic, ik weet het, maar nu kwam ik er net achter dat er al wel een tijdje high-speed camera's bestaan, en dat er op youtube natuurlijk ook mensen zijn die die al op beeldschermen hebben gebruikt

Wat ik vermoedde lijkt nu gewoon te kloppen, een klassiek 60Hz paneel heeft bijna 16ms nodig om alle pixels te switches.
Er zijn dus een 10ms waarin je de bovenste lijn van het volgende beeld en de onderste lijn van het vorige beeld ziet.

LCD:
YouTube: LCD Screen Refresh in 1000 FPS
YouTube: High Speed Video of LCD Refresh

CRT:
YouTube: TV screen refresh in Slow motion @ 10,000 FPS in UltraSlo

Dit is toch gelijkaardig aan tearing bij de bron?

[SA007]

Hier krijg je tearing door, daardoor heb je nu ook de 'nieuwe' standaarden als G-Sync (nvidia) en Freesync (AMD).

Daarbij synchoniseert het paneel het paneel deze interne frequentie met de FPS van de 3d renderengine.

[Adion]

G-Sync/Freesync helpt tegen jitter, waarbij de refresh exact start op het moment dat het beeld klaar is, ipv (zoals met v-sync) te wachten op de volgende refresh.
Zolang de pc krachtig genoeg is om exact 60 beelden per seconde te genereren was dit echter geen issue en voldoet v-sync prima.
Ook met freesync en g-sync zal het refreshen van 1 beeld op een 60Hz monitor niet sneller kunnen dan in 16ms. (al vermoed ik dat de meeste monitoren met deze technologie zowiezo 120Hz of meer monitoren zijn, waardoor de refresh vermoedelijk slechts 8ms duurt)

Feit blijft dat een animatie van iets dat snel horizontaal beweegt zelfs op een 60Hz monitor geen zichtbare tearing veroorzaakt zolang de bron gesynchronizeerd is (met v-sync)

Enige dat ik eigenlijk kan bedenken is dat je bij tearing aan de bron ervoor zorgt dat er een harde 1-pixel scheidingslijn is tussen vorig en volgend beeld, die bovendien een volledige cyclus zichtbaar blijft.
Bij de normale refresh is de scheidingslijn in beweging en door de traagheid van de pixels ook nog eens geblurred.
Toch zou je bij snelle panning verwachten dat je ziet dat de bovenkant van het beeld voorloopt op de onderkant.

Ik heb even getest aan de camera-kant, waar in principe hetzelfde verschijnsel op kan treden. Als ik snel met mijn telefoon een video maak en daarbij horizontaal beweeg, zie ik inderdaad dat rechte lijnen scheef lopen. Dit is zowel zichtbaar bij het afspelen als bij het pauzeren.

YouTube: Video Tearing test
Deze tearing test video lijkt het inderdaad wel lichtjes te vertonen. Als ik die full-screen afspeel en je let er op lijkt het er inderdaad op dat de lijn lichtjes scheef staat. Dat lijkt dan mijn vermoeden te bevestigen dat het probleem gewoon minder zichtbaar is omdat het geen vaste positie is waar tearing zichtbaar is (zoals bij tearing aan de bron), maar een verschuivend probleem zodat het beeld er nog steeds vloeiend uitziet.
Als ik dezelfde video op klein formaat afspeel (en de tijd die de monitor nodig heeft om dat deel te verkleinen dus een stuk korter is) lijkt de lijn rechter te worden.