• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Help on monitor strobe effect

Status
Not open for further replies.
V

velis

Senior member
You probably noticed in some movies how the wheels (of a carriage / car / bike) seem to stop rotating or rotate in the opposite direction from what they should be doing. Naturally, all a consequence of film only grabbing / displaying 24FPS.

OK, so now I'm attempting to reproduce the effect on my monitor using a simple program. The goal being that even if I rotate the wheel "smoothly", because of 60Hz refresh, I will only see a static image. Errrr - I hope I'm at least somewhat clear on this.

The algorithm is such that I rotate a bar. So, at 1 rotation per second this bar will go round and round smoothly. When I start approaching 60 rotations per second, the image I expect to see will be that of a slow backward rotation, at exactly 60 RPS it should be static and just after 60 RPS it should look like 1 RPS all over again.
My rendering algorithm achieves 150 FPS (very slow and crude I know, but I'm using GDI so I consider this a success).
At 60 rotations per second I achieve a more or less stationary image, but instead of only one bar showing, I see two. They are not completely white and (usually) form approx 50 - 60 degree angle.

The questions:
1. OK, two bars are possible if my pixel response is below 1/60sec == 17ms which I can't really test for. Or can I? Monitors nowadays shouldn't have such a low pixel response time, even if they are IPS. The monitor in question is Dell U2711.
2. Is this effect also possible as a result of 160FPS rendering vs 60Hz refresh rate of my monitor?
3. This might also be possible if my monitor actually didn't have 60Hz refresh rate, but something lower. In this case I would get to a single bar if I tried lowering the output refresh rate from my computer. I guess. Is this correct? But I'm also guessing in this case the resulting image shouldn't be so stationary as it is right now.
4. I could also imagine that the gfx card could be doing some frame interpolation, but find this utterly useless and pointless to be a plausible explanation.
5. Any other possible explanation?
 
Last edited:
Ahem

Maybe I got to a solution, but I'm not sure, so please if someone can confirm this:

Since the FPS and refresh rate are not in sync, I have the problem that renderer is rendering its own images and the RAMDAC is sampling that 60 times per second.
So I get the following "chart":
render degrees sample
_____72
1____144
_____216
2____288
_____360_____1
3____72
_____144
4____216
_____288
5____360_____1

When the first sample is taken, the second render is shown and that is with the "wheel" drawn at 288 degrees. When the second sample is taken, the wheel is at the expected position (at zero degrees position). This also suggests that my visual estimate of the angle (50 - 60 degrees) was wrong 😛
I see two bars because of combination of these two:
1. My eyes are slower than 60Hz so they make 1 blend of both images
2. Monitor has slow pixel response and leaves pixels on for too long

The second one possibly being negligible against the first one

Can I at least hope to be correct?
 
Last edited:
Sounds like tearing. If you can take a picture of it with a high shutter speed camera we can confirm this. An even easier way to test for tearing would be to flash the screen 100% black then 100% white as fast as possible and see if its one coherent image or multiple on your camera.
 
I'm perfectly aware of this. However, the particular test is intended to "reveal" the panel's native refresh rate. With this test one should be able to see that even if current refresh rate selected is 75Hz that his panel's actual refresh rate is 60Hz.
I realize that the refresh rates (between gfx card and monitor) don't differ that much and such a difference will be hard to observe, but I still believe the test may actually show any discrepancy between the frequencies.
That is why I need to render faster than reported refresh. The tearing resulting from such a discrepancy should be obvious then, but much less so if I rendered at exactly the reported refresh rate.
Or am I operating under wrong assumptions here?
 
Pixel response time is not a constant; it varies based on the colors being transitioned between. If you want to eliminate that as a factor, test with a CRT instead of an LCD.
 
The problem actually has nothing to do with the monitor/refreshrate/responsetime/eyes. It appears to be a problem with the timing of the program.

Aside from it obviously not working, this is a very very good idea velis. A lot of people can't tell the difference between 60hz and 75hz and they wouldn't be able to tell if their monitor was indeed running at 75hz or dropping the frames. TBH I don't know of a single monitor that does drop the extra frames, but it would be great to test just in case.
Once the timing is fixed, a 75hz monitor running the program at 75RPM would display a solid line. A monitor that drops frames would have lines all over the place when running at not its actual refresh rate.
 
@aluvus: this test is not intended for pixel response time. See Ben's post - he got it right.
That's the next test in the series. The third test will yield trapezoid moving rectangles when pixel response times are suboptimal. My U2711 yields quite severe deformations (somewhere around 10 degrees on each side), my friends TN monitor not so much.

@Ben: Well, the test does kinda work. 🙂 The bar is more or less static in it's 20 degree slack space when monitor's refresh rate is matched. If you go one RPS up or down, it will noticeably rotate vs previous "just flickering" around.

Obviously I'd need to render with vsync on to make sure I render the bar at the same place for each refresh, but I'm not sure this would eliminate the problem when the refresh rates actually differ. That's why I went for faster rendering, even if it means more flicker / tearing. Besides, I had serious trouble rendering text with wxGlCanvas 🙁

The problem with Windows GDI / API is that I can never ensure my timings except by actually hogging a CPU core in an infinite loop instead of relying on message queue as I do now. Even then there'd be some deviations, though minor.
 
Last edited:
velis said:
@Ben: Well, the test does kinda work. 🙂 The bar is more or less static in it's 20 degree slack space when monitor's refresh rate is matched. If you go one RPS up or down, it will noticeably rotate vs previous "just flickering" around.
Click to expand...
Unfortunately, the functionality of that single test seems broken for me. On my system, the point where the RPS and Hz match and we get that "flickery" bar changes from run to run. It seems to be +-10% at random, and sometimes never matches.

I have noticed that no matter the framerate or refresh rate, the program seems to be running at 1000FPS internally. At 1000RPS I get a perfectly solid bar at any refresh rate. 500RPS yields the program placings 2 bars 180 degrees apart. 250RPS yields 4 bars 90 degrees apart.

125RPS does 1 of three things for me, it either gives 8 bars 45 degrees apart, is very close to the meeting point for 120hz (which normally ends up being about 128RPS or 111RPS), or freaks the hell out in no specific pattern.
 
Hm, some very interesting results you got there.
You must have an insane beast if the program reports 1000 FPS (not RPS) to you. The program doesn't have any particular limitation for the FPS except for your CPU + GFX card power. I just render the pattern and immediately invalidate the window - thus causing yet another repaint.

My comp in comparison only manages some 260FPS (which gets rounded down to 240 for this test).

But the test results for 1000, 500, 250 and 125 RPS are strange indeed. The results you report suggest your gfx card and the panel have 1000Hz refresh rate, which is of course impossible. I have no idea why you should be getting this.
 
Status
Not open for further replies.

TRENDING THREADS

Back
Top