Blur Busters Forums

You made some good points! I thought it was a good idea, however you are right, there would be major issues for people with sensitivities to flicker (possibly me included) and lot's of other niggling issues that would make it feel inconsistent across the board.

I don't like the OP's idea. I would prefer G-Sync + strobing, even if it has to strobe as low as 30Hz. In fact, I would like it for 30fps games. It's a pity that BenQ Blur Reduction only works down to 50Hz (I'm still grateful it can do that).

I have come up with a different form of Adaptive GSYNC that is better:
http://www.blurbusters.com/faq/creating ... blerefresh

Also flickerfree!

Chief Blur Buster wrote:I have come up with a different form of Adaptive GSYNC that is better:
http://www.blurbusters.com/faq/creating ... blerefresh

Also flickerfree!

Is brightness of 10% PWM at 100hz really indistinguishable from 10% at say 10khz? Even if the number of photons are identical, I don't think the eye and brain respond perfectly linearly.

In any case, I think you can get similar results with just square wave PWM:

Split the PWM into two timers: one is low frequency, which controls persistence, one is high frequency, which controls brightness.

LF pulse width(in ms) = [current refresh interval] - [maximum dark time unnoticeable as flicker or minimum time to transition between frames].
HF duty cycle = [minimum LF duty cycle]/[current LF duty cycle]

I think this simplistic implementation would run into trouble when you try to implement low brightness settings, as you'd be using a lot of your PWM resolution just adjusting for refresh rate, and it's as easy to tell the difference between 1% and 2% duty cycle as it is to tell the difference between 50% and 100% duty cycle. There are a few ways around this, but that can be set aside for the moment in the interest of just getting some form of low persistence working on top of g-sync.

Chief Blur Buster wrote:I have come up with a different form of Adaptive GSYNC that is better:
http://www.blurbusters.com/faq/creating ... blerefresh

Also flickerfree!

Well, its not really flicker free..., ok its flicker free up to 59fps. And if ur fps is fluctuating around 60... i dunno about this.

However, i wanted to ask:

Currently monitors change picture by scanning the new one from top to bottom. (thx CRT)
How hard do you think it would be to send the whole picture without ever scanning it?
This would perma fix screen tearing.
And on displays that are not variable (say constant 100hz), if the video card fails to deliver enough frames, it repeats a previous one, which would just feel like low fps does. But screen tear would be gone and vsync with all its bullshit would be obsolete.

And then on a constant 100hz panel that doesnt scan, you could insert whole black frames(i mean strobe with full black frames instead of scanning them). I have a feeling this would be less shit as scanning black frames if flicker is concerned and could potentially bring pixel persistance down to 1ms.

Any thoughts on this?

Edmond wrote: However, i wanted to ask:

Currently monitors change picture by scanning the new one from top to bottom. (thx CRT)
How hard do you think it would be to send the whole picture without ever scanning it?
This would perma fix screen tearing.
And on displays that are not variable (say constant 100hz), if the video card fails to deliver enough frames, it repeats a previous one, which would just feel like low fps does. But screen tear would be gone and vsync with all its bullshit would be obsolete.

This is v-sync. Exactly v-sync.

And then on a constant 100hz panel that doesnt scan, you could insert whole black frames(i mean strobe with full black frames instead of scanning them). I have a feeling this would be less shit as scanning black frames if flicker is concerned and could potentially bring pixel persistance down to 1ms.

Any thoughts on this?

Basically, you're asking the display to buffer the top of the frame until it finishes receiving the bottom of the frame. This has no advantage over ULMB, because with ULMB you don't see the top of the frame until the backlight pulses, which happens after the bottom of the frame has scanned out. You have all the same problems and advantages as v-sync+ULMB. Or just v-sync if you decide not to do the black frame insertion.

To do this without "scanning out" you'd essentially need a parallel interface between the framebuffer and the panel, never going to happen. ULMB with g-sync would be better, but this requires more work to get consistent perceived brightness at varying framerates.

To make significant improvement over g-sync+ulmb you need to just keep pushing interface speeds and push framerate to match it.