Nézek itt egy gépet pixelhibák szempontjából,
töltögetek be iview képeket wav -ból (ez ugye tetemes időket emészt, egy -egy képnek a betöltése),
és ha betöltődött, akkor nem, vagy alig pixelhibásak a képek,
van amelyiknél nem látok mozogni semmit, és van amlyiknél néhol, egy -egy kis területen látok mozgást,
mely mozgások elhalhatnak, vagy beindulhatnak újra azon a területen, mivel egy TFT monitor scart bemenetén nézem, abban sem lehetek biztos, hogy azok egyáltalán pixelhibák, és egy crt monitoron is jelentkeznének mint pixelhiba,
(ha nem pixelhibák, akkor lehet hogy sokadik (kb. 8 körül) ep vásárlásomnál végre sikerült egy pixel hiba menteset kifognom),
de töltés közben van elég nagy mozgás és villódzás.
természetesen nem keverem össze magával a töltődéssel, ami egy függőleges, pixel hibázás sebességéhez képest lassú,
sávos változás a képtartalomban,
egyértelmű, komolyabb területek villódzásáról beszélhetünk a töltés folyamata közben,
és mire betöltődött, addigra eltűnnek a hibák, "megáll" a kép kivéve azt a néhány kis zizit, ami lehet nem is pixelhiba ...
én vagy arra gondolnék, hogy míg töltődik, addig színben nem hasonló árnyalatú pixelek vannak egymás mellett, mikor már betöltődött a kép, akkor ugye hasonló átmeneteket képező pixelek vannak ... és ezzel a pixelhiba összefügghet.
És itt jönne a valódi kérdés:
mikor egy iview kép töltődik befele, az ugye nem lehetséges, hogy a képek lpt -je valami FF szegmensen elhelyezkedő rendszerterületeket jelenít meg, ahol futó kódok változásait látom ?
mert ha nem, hanem egy konstans inicializálatlan területre tölt az iview, akkor az iview képek nem is az igazi megoldások a pixelhibák megjelenítésére,
mert ezen a gépen a képek szinte 100% -osak betöltés után,
hanem valami szintetikus teszt képernyőt kéne megalkotni, ami inkább hajaz az iview képek töltési állapotára, mint a betöltöttre (éles átmenetek kellenek).