Screen burn in reduction for OLED, PC CRT etc. with shifting scanlines.

[Paranoid_Andy]

Hey all,

I believe this is a pretty straightforward request and I think a lot of people could benefit from this.

As I understand it, when the color black is displayed on a OLED the voltage on that pixel is 0 or near 0 and pure white is max voltage or near max therefore causing higher temps eventually “burning” the screen explaining why brighter colors can burn faster.

A “scanline” then should be a very long-life friendly area of the screen then if the above is true.

I’d like a feature that has a simple timer the user can use to specify how often scanlines should automatically move ahead by 1 pixel.

So for example:
Using line 4x mode means there are 4 rows of potential scanlines to be shown.
1. I set scanline row 1 & 2 to 100% effectively reducing the image by half.
2. I then set the ‘shifting scanlines’ feature to 10 minutes.
3. The OSSC waits 10 minutes, then automatically changes the values of scanline rows 1 & 2 to 0% and sets rows 3 & 4 to 100%.
4. Another 10 minutes passes and the OSSC automatically changes the values of rows 1 & 2 back to 100% and rows 3 & 4 back to 0%.

The result being a slight image shift that allows all the pixels on 2 of the 4 rows to power down and cool off, while the other 2 rows are displaying color.

For people that don’t want to use such thick scanlines or line 4x this feature could still work. Line 5x with 1 of 5 scanlines active could just have the automatic timer set to 3 minutes and go down the rows 1 by 1 over the course of 15 minutes before starting over.

I have tested this setup myself by creating 2 separate profiles. Profile 0 has scanlines active on rows 1 & 2. Profile 1 has scanlines active on rows 3 & 4. I swap them every 10 minutes or so and played for well over 5 hours in my gaming sessions and didn’t see any issues at all at the end.

I took some screenshots of captured footage from the 240p test suite to help show what I talking about. The first image is 2 side by side screenshots. It’s 2 rows of pixels with scanline rows 1 & 2 on, then the other is scanline rows 3 & 4 on. The second image is a zoomed in section on the middle area of the first picture. It’s purpose is to show how the 2 actively drawn rows are not even with each other to show that indeed it is working.

View post on imgur.com

There is a slight bit of off-black color on some of the scanlines, mostly near the blue area. I think this is the image compression algorithm and not actually present.

I look forward to hearing what you all think of this.

Thanks again for the OSSC by the way. I love this thing!

[Author]

Posts