Vertical Retrace Sync with GDI/Win32

[jj2007]

Made 2 test progs, one with vsync on and one with vsync off.
Frames per second in the left upper corner.
On my computer both have smooth animations.

Both are smooth on my i5 if no other applications are active. But if I launch Task Manager side by side, i.e. half the screen for TM, the other half for the animation,
- cpu usage (ca. 7%) and frames (ca. 700) are much higher for the "off" version, and it's smooth
- cpu usage (ca. 1%) and frames (ca. 35) are much lower for the "on" version, and it's NOT smooth

That seems right the opposite of what johnsa wants to achieve ::)

[johnsa]

Ok.. the crash was me being silly, I told it to load the image from a resource and then put the filename in instead of the resource id so doh. I've put the resource back in and updated it to use the id so no extra bmp file required just the exe.

RRR, you were saying you have a lot of these strange crashes with x64 stuff, are you using jwasm or ml ? (I had a lot of that when I first moved to 64bit) but not since and it was always due to me trying to use push/pop
and not preserving regs properly.

The severity of the crash locking up the whole machine I can't explain, i reproduced the crash my side but it just terminated as expected. Sometimes I can get my apps freeze the entire pc including the mouse (so it's not even delivering interrupts to the OS) :) But that happens when I use my custom concurrency lib. I have usermode spinlocks and basically a micro-scheduler so i run tasks and parallel loops (without having to spin up threads all the time)... when I use all 8 cores (assuming Hyperthreading) and i get all 8 of them to die at the same time, then there is no escape.

The stutter really shouldn't be there, when I run it it's perfectly smooth until I press INSERT to switch off vsync. The only artifact you might see a bit of in both modes is some ghosting around the edges and thats due to the "fake-mode" background coppers, i believe it's sort of a combination of perception of vision and the monitor's response time to changing pixel colors. If i switch off the bkg coppers that goes away.

So now there are really two questions...
1) Why does having any other window open affect it at all, some runs I've noticed that the vsync seems to sudden loose sync as well... but that's intermittent..
2) WHY does the vsync not do what it's suppose to for you guys but it does for me..
     The only thing i can think re: 2 is that to enable the vsync I have to open a device by it's display ID, which for now I've set as //./DISPLAY1 (primary).
     The function in theory should be able to take ANY DC but it doesn't seem to work for me with that.

[rrr314159]

Ghosting is what I'm seeing, the edges are indistinct; not stutter (now that u mention it). I see 5 (I think) distinct boundaries instead of 1, close together. One time I got that because I was actually updating position incorrectly, moving it ahead and back quickly, but that was much more noticeable. As for crashes, the only problem I have is that it works fine on my machine but (sometimes) crashes on someone else's. As I said it seems to be fixed by re-compiling on the other machine; I'm guessing it's a problem with my Windows 8; the 8.1 machine does it much less, and it never happened with 7. I'm using H/JWasm, ML64 had too many limitations; that may have something to do with it, I don't know.

As for pushing, popping, and preserving registers - I'm pretty confident I know how that works, you get that way after decades of coding, begin to have the illusion you know what you're doing. Of course I screw up sometimes, but again, I've done that so many times, I really don't need any help there either.

[johnsa]

There seems to be a problem for me with H/JWasm at the moment, Jwasm13 works perfectly for me, but with H/Jwasm I get stack corruption and it also seems like some of the debug info is mis-aligned to locals.
This causes some really wierd random behaviour in places..
I'm busy investigating with Habran .. especially after he went to so much effort to add all the new features we discussed like vpgather's and rip relative addressing and support for the old fashion table+index addressing using RIP :)

I know when I was originally modifying jwasm with Habran to get debug info in 64bit mode right I used to have similar issues to the ones you mentioned if the stack arrangements weren't "debug" friendly.
But that all went way after our modifications/contributions to Japheths update (2.10 i think it was) to get proper debugging/symbols in 64bit.

Well i'm glad it's edge-ghosting and not stutter. To confirm it, I've attached a version with the checkboard/fake-mode removed so it's JUST the logo in the front.
Now you should be able to verify the difference between vsync and none and there shouldn't be any ghosting.

EDIT: To confirm another theory, if (in win7) I disable the dekstop composition of DWM (from Performance adjust visual effects) I can confirm that i can now see tearing and possibly dropped frames too, but definitely tearing thats not there normally, so the composition is forcing vsync for sure.

[johnsa]

Made 2 test progs, one with vsync on and one with vsync off.
Frames per second in the left upper corner.
On my computer both have smooth animations.

Both are smooth on my i5 if no other applications are active. But if I launch Task Manager side by side, i.e. half the screen for TM, the other half for the animation,
- cpu usage (ca. 7%) and frames (ca. 700) are much higher for the "off" version, and it's smooth
- cpu usage (ca. 1%) and frames (ca. 35) are much lower for the "on" version, and it's NOT smooth

That seems right the opposite of what johnsa wants to achieve ::)

Thats very strange, both are smooth for me :( I'll leave that one to Siekmanski to explain!! Perhaps it's gpu-driver related.

[Siekmanski]

Made 2 test progs, one with vsync on and one with vsync off.
Frames per second in the left upper corner.
On my computer both have smooth animations.

Both are smooth on my i5 if no other applications are active. But if I launch Task Manager side by side, i.e. half the screen for TM, the other half for the animation,
- cpu usage (ca. 7%) and frames (ca. 700) are much higher for the "off" version, and it's smooth
- cpu usage (ca. 1%) and frames (ca. 35) are much lower for the "on" version, and it's NOT smooth

That seems right the opposite of what johnsa wants to achieve ::)

Thats very strange, both are smooth for me :( I'll leave that one to Siekmanski to explain!! Perhaps it's gpu-driver related.

The only thing I can think of is that some background process sometimes uses all the cpu resources for periods longer then 16.667 ms.
So there couldn't be any update for the animation and it freezes from time to time.

@jj2007, can you test this one ?

[johnsa]

Ok, I've found some causes of stutter on my side, it looks "fingers crossed" like it's not happening at all for me now.

Please re-test and let me know if this is now smooth.

[Siekmanski]

It runs very smooth.
What causes the stutters ?

[johnsa]

I'm not 100% sure but I've made a bunch of changes:

1) Removed the FPS text (I was drawing that to the hdc after the frame was committed, so I think that might have caused the dwm some issue sync'ing up)
2) I realised that I'm not really that interested in the vblank, what I really want is the frame to be ready for the DWM to composite (as it's already vblank sync'ing). So i switch to using the dwm functions instead of the D3D kernel thunk.
3) I moved all the sync code into it's own thread which signals the render thread when to present, which either sleeps or can do other stuff waiting for a present interval.
4) I moved the whole present/flip operation into a parallel thread/async task so that if that delays for some reason it doesn't block the wait for the next vsync (what I loosely call it even though its more of a compositor/dwm sync).

So now I have to try undo them one at a time and see which one is the key to keeping it smooth.

[jj2007]

The only thing I can think of is that some background process sometimes uses all the cpu resources for periods longer then 16.667 ms.
So there couldn't be any update for the animation and it freezes from time to time.

@jj2007, can you test this one ?

CPU usage is dominated by Firefox and svchost.exe - nothing extraordinary. And it definitely stutters.

[rrr314159]

@johnsa,

new version still ghosting, might be a bit less, not 2 noticeable but definitely there. No stuttering at all. Dunno why others don't see ghosting ... ? BTW my monitor is 1920 x 1080, decent quality.

[johnsa]

The ghosting is ever so slightly  there because of what the background is doing.. if you press ESC (to pause) a couple different times, you'll see the background is actually flipping between odd/even rows in an interlaced fashion... you'll probably need to look in the dark areas where the copper bars aren't... Where that effect meets the solid edges of the stuff in front you get an optical illusion of ghosting.

That said it sounds like it might be a bit more pronounced for you, and this "could" be the video card driver. I get a similar thing specifically with some d3d/webgl apps i've seen although I can't think off hand which they were. Or perhaps your eyes are just very sensitive to the effect :)

[johnsa]

There seem to be two main causes of stutter that I've identified:

1) Writing the FPS out (AFTER the screen present) was a  bad idea. It's obviously forcing an invalidation of the device context and causing the compositor to not present that frame.
2) Some open windows seem to cause the DWM compositor to lose sync (Skype, when you have an unread message in orange on the taskbar) and Visual Studio (when it has an open modal dialog).. The open dialog thing could be generic across apps. My fix was to force a minimize off all windows on app start and then restore then at the end.

These two things combined have completely eradicated any stutter for me.