Refresh Rate Multitool .exe

[shurcooL]

Hello (to anyone interested in monitor Refresh Rates and are moderately advanced computer users, and are not sensitive to flashing lights),

I've made this extremely simple, but nonetheless quite handy (for at least 2-3 things) utility for monitor Refresh Rate testing.

All it does is display a sequence of easy-to-distinguish images with the Refresh Rate of your monitor. So at 85 hz, it will display 85 different frames (that are very easy to tell apart, so you'll know right away if your monitor doesn't actually display some), etc.

This is useful to confirm your [LCD] monitor can actually support more than 60 hz (e.g. like 75) without dropping frames, and to use as a more precise input lag test.

I'm posting it here in case anyone else might find it handy. I'm also open to (easy to implement) suggestions of how I can improve it, although it does everything I need from it already.

It's a little difficult to fully explain how to use this program properly. However, if you're an advanced user, and are interested in running these tests, you should be able to figure it out on your own after trying it out.

Use #1: A more precise input lag testing utility than a flash-based timer.
This image speaks for itself. Actually, it doesn't, and it's a little dark, so I gotta explain that it's two monitors. A 24" LCD on the left, a 21" CRT on the right. They are being driven by one video card set to Clone mode (i.e. same output to both monitors).

Both monitors were running at 1920x1200 at 60 hz (therefore 1 frame is 1000 ms / 60 = 16.7 ms).

It's taken with an exposure time of 1/60th of a second, which is why you're seeing exactly 1 frame on the CRT monitor (and why it's so dark).

(See attached image for another shot with an exposure time = 1/1600th of a second. Only a fraction of the full frame is traced by the CRT in that time.)

You're also seeing what the LCD is displaying during those exact same 1/60th of a second. It appears it only began turning the 3rd column white by the time CRT drew the whole frame.

So in this particular image, I would say the LCD monitor has about 2/3rds of a frame of input lag, and due to the slow pixel response time, you're seeing approximately 1 full frame in the past compared to the CRT monitor. So its effective input lag (for that particular image; you should take many pics and average them) is about 1 full frame, or 16.7 ms.

Use #2: So your LCD supports an input greater than 60 Hz: But can it really?
My 24" LCD monitor officially supports up to 75 hz vertical frequency. It does so only at lower res (1024x768 and lower I think), but for anything higher and up to 1920x1200 it can only accept 60 hz.

So I was playing some Counter-Strike at 1024x768 / 75 hz and something looked disturbingly wrong. I couldn't tell what it was, but the display did not feel very smooth, even though I was getting constant 75 FPS with v-sync on.

That's when I decided to create this thing. Much to my surprise, I was able to find out my monitor WAS NOT displaying all 75 frames when displaying a 75 hz input. It was only displaying 60 of those 75 frames, and dropping the rest. This created very jerky animation and was causing me headache. Now I know for a fact it can only display 60 hz inputs properly.

I've recently tested my older 17" Sony SDM-S71, which officially supports up to 85 hz, and found out it TOO only displays 60 images per second max.

WARNING: This application will produce FLASHING IMAGES to test your screen(s)!
If getting a seizure is a risk for you, close do not use it. I know very little about the dangers of flashing lights, so be careful. You've been told in advance what it does.

Usage: RefreshRateMultitool.exe [columns rows]
-columns - if specified, sets the number of columns, default 6
-row - if specified, sets the number of rows, default 1

Once you get past the warning screen, just resize the window to fill up a big portion of the screen and feel free to use this app in any way you can think of.

Legacy Download Link: https://github.com/shurcooL-legacy/RefreshRateMultitool/zipball/master
(Update in 2023: Blur Busters offers an actively maintained version of this tool, and much more, that runs in your browser. I recommend you use it instead: https://www.testufo.com/frameskipping.)

P.S. It's useful to have Fraps running alongside to make sure the FPS you're getting inside is exactly the same as your Refresh Rate you've set (and not fluctuating). This app enables V-sync, so it should be ok, but you never know.

P.P.S. If your Windows install is pretty fresh, you might get a "This application has failed to start because the application configuration is incorrect" error. You just need to download this redistributable package from Microsoft to fix that.

Please let me know if anyone finds this helpful. I know it's not very user-friendly, so I'm not expecting much. :]

 

[Sathsayin]

I did find this very useful it is exactly what i need to run some test and exactly what i described needing in this link.
http://www.hardforum.com/showthread.php?t=1364738

 

[shurcooL]

I've made an animated gif that visually demonstrates what this tool displays.

Of course, in reality, it shows 60 frames per second (or whatever your refresh rate is), so it runs much faster.

If your display is at 60 Hz, which is 1000 ms / 60 = 16.67 ms per frame, then the difference between two successive frames is 16.67 ms.

 

[pepos123]

Hi,

I believe you answered this in another thread but for the purpose of continuity on this thread, why/how is this setup better than the old fashioned timer in terms of measuring input lag?

I can't work out exactly why this would be other than the tearing issue? Could you explain for the rest of us dummies in this department?

 

[shurcooL]

Sure, I will try.

The idea is to capture many photos and see the difference between what's on two monitors.

In this photo, taken with a 1/60 exposure time, it captures one full trace cycle (from top to bottom) of the CRT on the right. Effectively, the CRT has drawn that one frame during those 16.67 ms.

If you look at the LCD on the left, you'll see it's displaying 1/3rd of 2 frames ago, full 1 frame ago, and 1/3rd of the current frame (displayed by the CRT). So it looks like the LCD is behind the CRT by one full frame, or 16.67 ms.

If you were to use a timer app, then the CRT would clearly display some time, whereas the LCD would display a mix of times from 0, 1, and 2 frames ago. I think it'd be harder to understand what the LCD was showing exactly.

Hope that helps!

 

[Godmachine]

Bravo dude for making a solid app to help out with this very technical issue.

 

[stephen0983]

interesting app, did you use a digital camera to take the pictures with different exposure lengths?

 

[shurcooL]

Yep. Here's a shot with an exposure time = 1/1600th of a second. Only a fraction of the full frame is traced by the CRT in that time.

So, during this shot, the CRT was about 40% done tracing the 4th vertical bar frame.

Meanwhile, the LCD was still displaying 80% of the 3rd frame (i.e. 1 frame in the past) and 20% of the 2nd frame (2 frames in the past).

 

[bb23]

Thanks a lot for this very cool tool!

ToastyX mentioned it for input lag testing on the HP ZR24w thread, so I thought I should post the test pics and his (and another person's) analysis of the results here too.

Anyway, I set up a Dell 15" CRT and the HP ZR24w in clone mode at 1280x1024 (the Dell's max) using the input lag test ToastyX referred us to here:
http://hardforum.com/showthread.php?t=1423433

So here are a bunch of shots with the Dell on the left, the HP on the right:

1 - HPZR24W vs. Dell CRT
2 - HPZR24W vs. Dell CRT
3 - HPZR24W vs. Dell CRT
4 - HPZR24W vs. Dell CRT
5 - HPZR24W vs. Dell CRT
6 - HPZR24W vs. Dell CRT
7 - HPZR24W vs. Dell CRT
8 - HPZR24W vs. Dell CRT
9 - HPZR24W vs. Dell CRT
10 - HPZR24W vs. Dell CRT
11 - HPZR24W vs. Dell CRT
12 - HPZR24W vs. Dell CRT
13 - HPZR24W vs. Dell CRT
14 - HPZR24W vs. Dell CRT
15 - HPZR24W vs. Dell CRT
16 - HPZR24W vs. Dell CRT
17 - HPZR24W vs. Dell CRT
18 - HPZR24W vs. Dell CRT
19 - HPZR24W vs. Dell CRT
20 - HPZR24W vs. Dell CRT
21 - HPZR24W vs. Dell CRT
22 - HPZR24W vs. Dell CRT
23 - HPZR24W vs. Dell CRT
24 - HPZR24W vs. Dell CRT
25 - HPZR24W vs. Dell CRT
26 - HPZR24W vs. Dell CRT
27 - HPZR24W vs. Dell CRT
I will just post these and hopefully the experts can comment on them. Oh yeah, generally my camera snapped these at 1/60, but sometimes it was 1/40 or 1/30. Not sure if that would matter - I think not, but I am not certain.

Those shots show the HP has no significant lag, maybe 3 ms max + pixel response time. The bars are drawn from left to right, so the newest right-most bar is what you want to look at. The total transition time is less than a frame. The results seem consistent too, with no tearing. Interestingly, picture #20 shows the program skipped a frame for some reason, but that doesn't change the results.

In considering this today I am wanting to make sure I know how you came to this conclusion.

It looks to me like the HP is about 1/2 to 2/3's of a bar behind the CRT. Given the 5ms pixel response rate accounts for about 1/3 of a frame's worth of delay (16ms per frame divided by 5ms = 1/3) the other 1/6-1/3 of a frame delay would be another 2.5 ms to 5 ms, for a total between 7.5 ms and 10 ms of input lag. If this is validated to be the case, it certainly bodes well for this otherwise very nice (especially for the price) monitor, imo.

It does seems to me that the delay is between 1/2 frame to 2/3s of a frame - on average. I guess this is immaterial as it implies that the panel suffers a minimal delay in either case, at least half of which is the pixel response rate.

So, given the pixel response rate of 5ms for this panel does account for half of the above delay, it must matter what response rate a monitor has even in terms of input lag. Is this actually correct? I keep reading that input lag and pixel response rate are independent, but in your analysis the latter certainly directly affects the former - which makes sense to me. Edit: Yeah, obviously the pixel response rate affects the time it takes for the monitor to render the bars.

The bar starts to show on the HP within about 3 ms of the CRT. The gradient fading in is due to the pixel response time.

Response time specs are not accurate. It's like they just make up numbers now. The best case scenario gray-to-gray response time with overdrive on might be 5 ms, but even that is suspect. IPS panels take maybe 7-10 ms for a black to white transition to complete, so if you want to consider the total transition time, it might be 10-13 ms. It's hard to pinpoint an exact number.

People say lag and response time are independent because response time specs don't include lag. Some "8 ms" monitors have two frames of lag, which would be at least 33 ms. The response time starts after the lag ends.

I think it's only fair to include the pixel response time in lag measurments. For the time being I decided to standardize on 50% pixel response or so:

Using this method I got an average total response of 13.4 ms to 50% pixel change per bb23's pictures.

I'll post some pics later to better explain how I calculated this ... no imageshack here

That's pretty good. And if this monitor will do 75 or 80 Hz proper, that would make it a real winner for gaming.

Thanks for your analysis. I am looking forward to your pics and further explanation.

The problem is the pixel response time varies depending on what colors are changing and whether or not there's overdrive.

I prefer to think of it this way: Beyond the lag, it's going as fast as the technology allows, so I don't worry about response times. I just care if there's a significant delay before the frame is displayed.

Good stuff. I am thinking I should re-post some of these posts on the input lag thread because they have been very helpful in explaining that test further. Is that okay with you guys?

How I calcualed lag. I used response to 50% pixel change. Anyways I got 13.4 ms, which is really good.

This is assuming VSYNC was working perfectly and there was no delay on the cloning.

13.4 is fast, will be pretty good for gaming. I would consider this a great gaming monitor if it can do 75, 80Hz or so. My Dell 2209WA is great and 76Hz makes a notable improvement. This coming from a CRT freak/LCD hater. Higher refresh is great in that it also serves to reduce input lag, reduce vsync induced lag, but also reduces the effects of tearing with no vsync. Oh, and it makes things smoother. Don't forget about that one.

I think IPS would be just fine with 120Hz, even if the pixel response isn't 100% up to snuff. Many of the major benefits would still present themselves, but 3D shutter applications may not work so well.

http://www.mediafire.com/imageview.php?quickkey=jzq5in0zgng

http://www.mediafire.com/imageview.php?quickkey=vz5xnjwwyw3

According to your equation, the lag is 7-8 ms.

You included the oldest bar fading out as part of the average, which isn't fair because LCD monitors are sample and hold displays, so the oldest bar on the LCD will always fade out one frame later than a CRT because a CRT begins to fade out as soon as the area is refreshed, while an LCD will keep the frame on the screen until the next refresh.

You only want to look at the newest bar fading in because that's the actual lag.

Hmmm, thinking again about the over-exposure of the image. That would mean the start of the black point on the LCD would be masked because the white is clipped until it becomes far darker then what is really 50% in reality. That means the beginning of the black point may be as far as 3.9 or 4.0 in image 2, putting the lag at closer to 8ms. Given the overexposure, one this is for sure, my "to 50% pixel response" analysis is not accurate here!

I'll revise my estimate to ... 3/17 ms (upper/lower bound) with a contingency for 3/33.67 ms given the lack of info on vsync and clone lag in this setup. I'm pretty confident with 3/17 ms, though. I'll leave it at that since I don't own this monitor or anything.

I'm happy with my 2209WA for gaming until something much better comes along like OLED with <5ms and 120Hz, 120Hz IPS with 1000+ contrast ratio and <8ms lag, 120Hz MVA/S-PVA for ~2000+ contrast ratio with <8ms lag (surely this can be done even with the buffering requirments of overdrive. just run it at 240Hz for processing if necessary; at 240Hz you can buffer 2 frames and still keep 8.33ms lag. Heck ,give me an OLED 240Hz with 13440 x 8400 resolution so we can get that perfect scaling for all resolutions.

This one looks good though. It definitely qualifies as a 'high performance" 60 Hz, IPS display as HP intended.

Has anyone tried to force higher refresh rates and test for frame dropping yet?

 

[cybereality]

Great tool, awesome work. However, I don't understand how to tell if frames are being dropped. Basically, I am using a 120Hz LCD monitor, and it doesn't seem like the Windows desktop is actually updating at 120Hz (because of blur when dragging windows around, etc.). When I run FRAPS it says 120fps, and this refresh rate tool appears to be working. But I think something is wrong. How do I know if Windows is really running at 120Hz?

 

[shurcooL]

Thanks.

First, you should understand that a 120 Hz LCD will not have less blur (vs. 60 Hz) when moving windows around, as that is related more to the pixel response time. 120 Hz would only make the movement more smooth, since there are twice as many intermediate frames being drawn.

To answer your question (how to use my tool to see if frames are dropped), it depends on the situation.

For example, if your LCD panel runs at 75 hz but you think in reality it's only showing 60 hz, then you run it with 5 boxes. You should only see 4 out of 5 boxes if it's actually only displaying 60 hz (i.e. dropping every 5th frame), or all 5 boxes if it's truly displaying 75 hz.

In your case, I would run it with 6 columns and 2 rows of boxes. If it runs at 120 FPS and you see only 6 out of 12 boxes being consistently lit up, then it's only displaying 60 out of 120 frames per second. But if you see all 12 boxes lighting up, then it's really 120 hz.

Hope that helps! Lemme know if you need more help.

 

[kalston]

Wow thanks, I gotta check that out later on.

 

[vafan13]

I've noticed, for me at least, that if I move the mouse around while it's running I notice it looks like it's dropping a significant number of frames. Is this normal?


edit: well that's not good, just tested it on another computer/monitor and it didn't do it. hmm

 

[shurcooL]

vafan13, that doesn't happen to me. I get a constant 60 FPS (seen via Fraps) when moving the mouse and not.

There's nothing in the code that would do it on purpose. So most likely it's just some driver issue with your computer. I would just ignore it and not move the mouse during testing (as long as your games run fine).

 

[cybereality]

Great tool, and it indicated there was nothing wrong with the monitor's refresh rate. My problem ended up being the mouse I was using (Logitech M500) which seems to have a slow polling rate (maybe 60Hz). So when I was dragging windows around it looked choppy because of the mouse. Really annoying. Switched to some $5 spare I had and everything is silky smooth.

 

[vafan13]

vafan13, that doesn't happen to me. I get a constant 60 FPS (seen via Fraps) when moving the mouse and not.

There's nothing in the code that would do it on purpose. So most likely it's just some driver issue with your computer. I would just ignore it and not move the mouse during testing (as long as your games run fine).

yeah fraps FPS doesnt seem to move, i just see random bars going "solid" for an instant. I just tested it with the monitor (and cable) that worked fine on the other computer and it does it with that one too on this computer. Odd. Are you using XP or win7?

 

[shurcooL]

Great tool, and it indicated there was nothing wrong with the monitor's refresh rate. My problem ended up being the mouse I was using (Logitech M500) which seems to have a slow polling rate (maybe 60Hz). So when I was dragging windows around it looked choppy because of the mouse. Really annoying. Switched to some $5 spare I had and everything is silky smooth.

I'm glad it was useful. Yeah, I've only realized how awesome my G9 is after using a CRT at 150 Hz and seeing the cursor trail become much more dense. The mouse does 500 reports/second (but not 1000... I had another utility to test that lol).

I just tested it with the monitor (and cable) that worked fine on the other computer and it does it with that one too on this computer. Odd. Are you using XP or win7?

Not exactly sure what you mean, but I wouldn't worry about it anyway. Just don't move your mouse. ;D I've got XP on this computer, but I'm pretty sure it works equally fine in 7.

 

[vafan13]

Not exactly sure what you mean, but I wouldn't worry about it anyway. Just don't move your mouse. ;D I've got XP on this computer, but I'm pretty sure it works equally fine in 7.

computer A (my computer) was doing it. Computer B wasn't. To see if it was the monitor causing it I took the monitor from comp B and attached it to comp A. It still did it so it wasn't a fault monitor or cable causing it.

 

[kalston]

computer A (my computer) was doing it. Computer B wasn't. To see if it was the monitor causing it I took the monitor from comp B and attached it to comp A. It still did it so it wasn't a fault monitor or cable causing it.

High USB polling rate (from 500 and above) can take a noticeable amount of CPU depending on your rig. Some mobos can't handle it too well either. What mouse, cpu and mobo do you have?

 

[vafan13]

Razer imperator, ASRock extreme6 and i7-2600 at 4.8Ghz

I'll try another mouse for kicks.

 

[atracious]

I bought a monitor with a 2ms response time (reportedly) and I'm looking for a way to test it, would this do the trick? would I have to force my comp into 120hz? can I do that on Win7?
Thanks for your help in advance!

 

[atracious]

Thanks.

First, you should understand that a 120 Hz LCD will not have less blur (vs. 60 Hz) when moving windows around, as that is related more to the pixel response time. 120 Hz would only make the movement more smooth, since there are twice as many intermediate frames being drawn.

To answer your question (how to use my tool to see if frames are dropped), it depends on the situation.

For example, if your LCD panel runs at 75 hz but you think in reality it's only showing 60 hz, then you run it with 5 boxes. You should only see 4 out of 5 boxes if it's actually only displaying 60 hz (i.e. dropping every 5th frame), or all 5 boxes if it's truly displaying 75 hz.

In your case, I would run it with 6 columns and 2 rows of boxes. If it runs at 120 FPS and you see only 6 out of 12 boxes being consistently lit up, then it's only displaying 60 out of 120 frames per second. But if you see all 12 boxes lighting up, then it's really 120 hz.

Hope that helps! Lemme know if you need more help.

I bought a 2ms response time monitor, would this also test that? would I have to force my computer into 120hz? How can I do it on win 7?
thanks in advance

EDIT: sorry about the double post, I didn't see that it put my post on the second page, so I thought it didn't work >.>

 

[shurcooL]

You don't have to force your monitor into anything it doesn't support, just use it normally. Use 120 hz refresh rate only if it supports it.

I'm not sure what exactly you want to test... Is it the 2 ms response time?

Then you can try running it and take some photos with as low exposure time as possible. Then look at what the photos caputered. If there are lots of bars lit up at the same time, it's because the response time is not so great. If it's as low as 2 ms, then there should be pretty fast transitions from black to white and white to black.

Edit: But make sure your photos' exposure time is really low, at least under 10 ms. If you take a photo with exposure time of 250 ms, then every bar will be lit up regardless if you have a 2 ms response time monitor or 500 ms one.

 

[Neochrome]

Hello, I just registered here, in fact just because of this request to you shurcooL. Would you mind uploading your Refresh Rate Multitool utility somewhere else? You know, Megaupload is down.

I am fortunate owner of DELL 2209WA (almost one year - one of the last manufactured), and I must say, after reading some articles, that panel ROCKS! Through nVidia Control Panel, I just unlocked 76Hz refresh frequency, and I just want to be 110% sure, that it's not frameskipping. Thank you.

 

[shurcooL]

Sure thing.

I've edited my original post and there's a reply below with the latest download link.

 

[Neochrome]

Thank you once more :]

 

[shurcooL]

This has been unexpected, but it seems this utility is regularly getting almost 100 downloads each month. Even after I was forced to insert a space into the download URL, so I'm pretty sure it's not bots.

Because of that, I've decided to give RefreshRateMultitool a better home, as an open source project at GitHub. This way, if people are curious to look at the source or want to fork it and submit pull requests, it can be done more easily.

So the new download link for the latest version is: http://goo .gl/IJkrf (again, remove the space)

The GitHub project is here: https://github.com/shurcooL/RefreshRateMultitool

 

[dowant120hz]

High USB polling rate (from 500 and above) can take a noticeable amount of CPU depending on your rig. Some mobos can't handle it too well either. What mouse, cpu and mobo do you have?

its far below 1% really
high cpu load while quickly moving the mouse only happens on the windows desktop
and that's only due of a very old explorer bug that still isn't fixed

 

[An00bis]

This has been unexpected, but it seems this utility is regularly getting almost 100 downloads each month. Even after I was forced to insert a space into the download URL, so I'm pretty sure it's not bots.

Because of that, I've decided to give RefreshRateMultitool a better home, as an open source project at GitHub. This way, if people are curious to look at the source or want to fork it and submit pull requests, it can be done more easily.

So the new download link for the latest version is: http://goo .gl/IJkrf (again, remove the space)

The GitHub project is here: https://github.com/shurcooL/RefreshRateMultitool

thank you for the time you put into creating it, I'll try to use it maybe I'll get a little more out of my monitor.

 

[kalston]

its far below 1% really
high cpu load while quickly moving the mouse only happens on the windows desktop
and that's only due of a very old explorer bug that still isn't fixed

Are you sure? I noticed MASSIVE fps drops with my polling rate at 1000hz on my old e8400. 500 was loads better. I would not worry about the CPU usage on a Quad Core though.

 

[Zotya]

Thanks.

First, you should understand that a 120 Hz LCD will not have less blur (vs. 60 Hz) when moving windows around, as that is related more to the pixel response time. 120 Hz would only make the movement more smooth, since there are twice as many intermediate frames being drawn.

To answer your question (how to use my tool to see if frames are dropped), it depends on the situation.

For example, if your LCD panel runs at 75 hz but you think in reality it's only showing 60 hz, then you run it with 5 boxes. You should only see 4 out of 5 boxes if it's actually only displaying 60 hz (i.e. dropping every 5th frame), or all 5 boxes if it's truly displaying 75 hz.

In your case, I would run it with 6 columns and 2 rows of boxes. If it runs at 120 FPS and you see only 6 out of 12 boxes being consistently lit up, then it's only displaying 60 out of 120 frames per second. But if you see all 12 boxes lighting up, then it's really 120 hz.

Hope that helps! Lemme know if you need more help.

Hi!

I just found your tool, and i'm not sure how to use is to test for dropping frames. I'm into hd movies, so 71,928 or 47,952 hz are important to me, i already added these refresh rates with CRU. My monitor accepts both of them, but my mouse acting strangely in both refresh rate. I already checked my mouse with mouserate, and it says 124hz which is fine i think. The mouse movement is not so continous than in 60 hz.

I tried your tool with the default 6 columns (with 5 it crashes) and with ~48hz all of the columns flashes more or less regurarly, in ~72hz, all of the boxes flasing, but i think only 5 from 6 at one time, and 1 is not. The one which not flashes is always wanders from left to right.

Thank you for your help!

 

[livefastdieyoung]

I already checked my mouse with mouserate, and it says 124hz which is fine i think.

mouserate displays usb polling rate, not screen refresh rate.

The mouse movement is not so continous than in 60 hz.

I tried your tool with the default 6 columns (with 5 it crashes) and with ~48hz all of the columns flashes more or less regurarly, in ~72hz, all of the boxes flasing, but i think only 5 from 6 at one time, and 1 is not. The one which not flashes is always wanders from left to right.

your screen is dropping frames at 72hz.

 

[Zotya]

mouserate displays usb polling rate, not screen refresh rate.




your screen is dropping frames at 72hz.

Yes i know, but i think if the polling rate is higher than display hz, then it is fine. Or not?

The mouse in 48hz behaves the same as 72hz, why?

 

[livefastdieyoung]

Yes i know, but i think if the polling rate is higher than display hz, then it is fine. Or not?

it's fine, but usb polling rate has nothing to do with display refresh rate.

The mouse in 48hz behaves the same as 72hz, why?

because the monitor's electronics simply won't refresh the panel at those rates. it may accept them as valid input rates, but will still refresh the panel at 60hz, and drop frames to make up the difference. you will see this as choppiness.

 

[Zotya]

it's fine, but usb polling rate has nothing to do with display refresh rate.



because the monitor's electronics simply won't refresh the panel at those rates. it may accept them as valid input rates, but will still refresh the panel at 60hz, and drop frames to make up the difference. you will see this as choppiness.

I think there is a misunderstanding here. My English is maybe not so good or something, but you're not answering my question.

edit: you said my display is dropping frames at 72hz, but my mouse behaves the same in both 48 and 72 hz. Its movement is not so continous than in 60hz. I'm curious what the reason of this.

 

[shurcooL]

It's probably dropping (or doing something else weird) frames at both 48 and 72 hz then.

Try running it with different parameters, like 4 1 or 5 1 or 7 1, etc., and check that all of the squares are lit up regularly, without any being skipped.

So the exact command line would be:

RefreshRateMultitool.exe 4 1

I tried your tool with the default 6 columns (with 5 it crashes)

It shouldn't be crashing. Can u send me a screenshot of how you're starting it? If I understand the problem, I'll fix it.

 

[Zotya]

It's probably dropping (or doing something else weird) frames at both 48 and 72 hz then.

Try running it with different parameters, like 4 1 or 5 1 or 7 1, etc., and check that all of the squares are lit up regularly, without any being skipped.

So the exact command line would be:

RefreshRateMultitool.exe 4 1

It shouldn't be crashing. Can u send me a screenshot of how you're starting it? If I understand the problem, I'll fix it.

Thanks! The crash was caused by improper command line usage (i only specified the columns count).

I lowered the values in both HZ in CRU, the 48hz seems good to me, but no change in 72 hz.
I added 24 Hz too, well this is very slow in windows, your program in this Hz is like in column is white at a time, and this going from left to right. But the funny part is, the blu ray movies seems completely fluent in 24 Hz, and in 48 Hz too. Only the 72hz is problematic. But i can still lower its values in CRU further.

 

[Haldi]

Hi,

is there any way to force the Tool to run in 120 FPS ? i Wonder what happens when you have 90FPS but the monitor refresh in 60hz...

 

[shurcooL]

By default, it runs with vsync on, so it will run at 120 FPS if your monitor is running at 120 Hz.

If you make the app run at 90 fps on a display running at 60 hz, you will definitely see a lot of image tearing, and there will be artifacts because of the FPS and refresh rate mismatch.

 

[Haldi]

That's exactly what i'm hoping to achieve!