Stutter after refresh rate change (3 Viewers)

[gibman]

Interesting, looking at the code, it seems that only the dwm hack is carried out when using internal refreshrate changer and not when using the external one.

look for : RunExternalJob, it returns true if it succeeded in running the external job, and false otherwise.
This should also be included.

  if (newExtCmd.Length == 0)
        {
          Log.Info("RefreshRateChanger.SetRefreshRateBasedOnFPS: using internal win32 method for changing refreshrate. current is {0}hz, desired is {1}", currentRR, newRR);
          Win32.CycleRefreshRate((uint)currentScreenNr, newRR);
          NotifyRefreshRateChanged(newRRDescription, (strFile.Length > 0));
        }
        else if (RunExternalJob(newExtCmd, strFile, type, deviceReset) && newRR != currentRR)
        {
          NotifyRefreshRateChanged(newRRDescription, (strFile.Length > 0));
        }

/gibman

 

[nyt]

I tried invalidating the window, and tons of other things that just should work but didn't. I'm not sure if this is a directx/dwm bug or if there's some way to tell dx/dwm/windows/whatever that the refresh rate changed and to stop being stupid.

In my opinion it is a OS side bug, so thats why we might need such ugly hack to be used. OS side bugs tend to be really hard to fix as most of the time developers are searching the bug in the own code, like Scythe did

Really? This used to not happen all the time. I wonder if something in the graph building is causing it, this got worse in the Christmas build.

Interesting, looking at the code, it seems that only the dwm hack is carried out when using internal refreshrate changer and not when using the external one.

look for : RunExternalJob, it returns true if it succeeded in running the external job, and false otherwise.
This should also be included.

/gibman

new patch/dll attached. I haven't tested it yet, but I don't see why it wouldn't work, but then again I haven't slept, so someone can let me know.

 

[anvandarnamn]

seems to be working fine!

great work man!

About 1 time of 10 it still stutters though :-( , but still a great improvement!!!

 

[Scythe42]

I'll wait a few days more for some more feedback before committing the change to SVN.

 

[anvandarnamn]

seems to be working fine!

great work man!

About 1 time of 10 it still stutters though :-( , but still a great improvement!!!

after some more testing i cant get it to stutter anymore !!!!!

happy times!


now there is just the problem with randomly dropping frames with certain decoders (like libavcodec) anyone knows why this is happening?

 

[Jay_UK]

Hi there,

I've installed the new core.dll - I'll see how it performs over the next day or two and feed back.

Many thanks to NYT, Scythe42 and everyone else involved

J.

 

[edterbak]

Hi,
Im just reporting my finds with running xp + vmr9. It runs ok. No problems I found so good news there.

[edit]
I do have some occasional judder. It is so irregular that it cant be related to this thread. Sometimes a 30sec to a minute with perfect screen and then suddenly a few dropped frames.
My bet on this is on the codec side. Most of the judder files I see have out of sync audio as well. This supports the codec thing.

Thing I do notice is the fps indication (shift+1) sometimes makes no sense. 48fps? or 28... looks weird, but image is good

So, good work here

 

[fillerguy]

working great here too, going from 60->24->60hz .

 

[drealit]

I can confirm that the work around is functioning fine for me. 60 > 24 > 60...

 

[onyx666]

i did not have any stuttering yet so it looks to be working.

i still have a constant audio delay in 24hz (around 200ms) is someone else having this issue ?
could it be a cpu problem ? ihave a 4850e cpu