アカウント名:
パスワード:
フリッカーは、「可変リフレッシュレートの変更頻度がMacは特異だった」ってことでしょ。数フレーム単位でレートを変える意味がよくわからんけど、こんな頻度でレートを変えられるとモニタ側がシンクするのがメチャクチャたいへんそう(表示を崩さずレート変更を試みている最中にレートを変えられて、それに対応しようとしているうちに、またまた変えられて…)。
一方焼き付きの方だけど、これはCRTのように永続的に焼き付いているわけじゃなくて、正確に表現すると「残像」だよね。これはEIZOによれば [eizo.co.jp]「液晶パネル内の微少な不純物のせい」だそうな。Macで騒がれるのは、この不純物が散りにくい使い方をするせい?
フレームレート変更後に必ず正側から駆動するような制御が入ってるとか、そういう感じでしょうか。偶数フレーム後にレート変更なら平均ゼロで問題ないけど、奇数フレーム後に変更するとDC成分が残る。普通は頻繁にレート変更しないか問題起きないけど、数フレーム間隔で変更なんてされると影響出るとか。
そうか、DCずれが起こってるのかしっくりきた。> 偶数フレーム後にレート変更なら平均ゼロで問題ないけど、でも表示にフレーム相関なければアウトだからフレームレートの変更ステップが過剰なんじゃないかな。しっかし、LCDの原理も知らない奴がコンピュータ作ってんのかよ。やれやれ。
出力側があらゆる表示素子を想定して信号を送信しなければならないと?ディスプレイメーカーが使用する素子に合わせてうまくやる話では
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
フリッカーと焼き付きは別問題 (スコア:0)
フリッカーは、「可変リフレッシュレートの変更頻度がMacは特異だった」ってことでしょ。数フレーム単位でレートを変える意味がよくわからんけど、こんな頻度でレートを変えられるとモニタ側がシンクするのがメチャクチャたいへんそう(表示を崩さずレート変更を試みている最中にレートを変えられて、それに対応しようとしているうちに、またまた変えられて…)。
一方焼き付きの方だけど、これはCRTのように永続的に焼き付いているわけじゃなくて、正確に表現すると「残像」だよね。これはEIZOによれば [eizo.co.jp]「液晶パネル内の微少な不純物のせい」だそうな。Macで騒がれるのは、この不純物が散りにくい使い方をするせい?
Re: (スコア:1)
焼き付くとCOM電圧がずれるのでフリッカーも発生
原因を想像すると、
数フレーム単位でレートが変わる際に、正負の電圧が交互にならずにどっちかに偏るんじゃないかと思う
もしくは、奇数フレーム数のレート変更が正負の電圧印加を蓄積させてるのかもしれないが可能性は低いと思う
LCD内のTconで正負の電圧印加をカウントして、平準化しているモデルは焼き付かないと思うけど、
数フレーム単位のレート変更は想定外だったので、Tconで正負電圧をカウントしてなかったんでしょうね
Re: (スコア:0)
フレームレート変更後に必ず正側から駆動するような制御が入ってるとか、そういう感じでしょうか。
偶数フレーム後にレート変更なら平均ゼロで問題ないけど、奇数フレーム後に変更するとDC成分が残る。
普通は頻繁にレート変更しないか問題起きないけど、数フレーム間隔で変更なんてされると影響出るとか。
Re: (スコア:1)
そうか、DCずれが起こってるのかしっくりきた。
> 偶数フレーム後にレート変更なら平均ゼロで問題ないけど、
でも表示にフレーム相関なければアウトだからフレームレートの変更ステップが過剰なんじゃないかな。
しっかし、LCDの原理も知らない奴がコンピュータ作ってんのかよ。やれやれ。
Re:フリッカーと焼き付きは別問題 (スコア:0)
出力側があらゆる表示素子を想定して信号を送信しなければならないと?
ディスプレイメーカーが使用する素子に合わせてうまくやる話では