Hey all,
I know in theory there is no provision for this at all, there is no way to wait for Vertical Blanking without using Direct3D/DXGI, OpenGL (both indirectly through it's present functions) or legacy DirectDraw which is slow and deprecated. That said I did come across the following:
Win7 DWM can be switched off but for most users it's on, Win8+ it's always on. As such you have access to DwmFlush and DwmGetCompositionTimingInfo functions (from dwmapi.lib)
The composition timing info gives you back
qpcVBlank = The query performance counter value before the vertical blank.
There are a number of other fields in the structure returned:
rateRefresh =The monitor refresh rate.
qpcRefreshPeriod = The monitor refresh period.
So in theory using that value it should be possible to determine the next point for a vertical retrace start, DwmFlush in theory might also be useable.
I've tested DwmFlush and it definitely limits my FPS to 60 I'm just not sure on the best way to use it.
I was wondering if anyone else had experimented with these as a way to gear tear-free/vsync'ed software rendering in a window or from GDI etc.
I found some bugzilla threads where it appears Chromium and FF have used or considered to use this approach for their Silk and smooth scrolling implementations.
Hi, JOHNSA,
When I first read your post, I wasn't sure what you were talking about,...
So,...I Googled it:
Detecting Vertical Retrace in Microsoft Windows (http://www.compuphase.com/vretrace.htm)
Understanding Synchronization in Real-Time 3D Graphics (http://andesengineering.com/OSG_ProducerArticles/Synchronization/index.html)
...I was wondering why this was a significant issue,...and the author of the first article explained it:
QuoteTearing occurs when an object's position changes and electron guns of the CRT update the new and/or old areas of the object during the blit operation. If that happens, the computer display will show a situation where the top part of the image is updated and the bottom part that lags a frame behind (assuming that the blit goes top-down). This situation will only exist for a fraction of a second: if the vertical refresh rate of the monitor is 60 Hz, the display is updated 17 ms later. However, it exists long enough for us to perceive an irregularity in the object's shape, possibly due to phosphor afterglow. To avoid tearing, you should do blit as much as possible during the vertical retrace period. Therefore, it is necessary to be able to detect the start of the vertical retrace.
That's exactly it.
The compuphase article pretty much covers why you would want to do it, however it's way out of date and using the standard VGA compatible status register read is no longer really valid (How I miss the DOS days..).
It requires:
a) a driver for ring0 port-reading and
b) most likely unsupported on any modern graphics card that supports multiple monitors especially if it's been fully configured by a driver and not running in a legacy "vga-compatible for boot" mode.
Some days I really think we have regressed.. compare intialising direct2D to the good old:
mov ax,13
int 10h
Any way.. the point is using a graphics API like DirectX allows you to enable swap chains/buffer presentation with or without waiting for vertical retrace and will obviously also support the new GSync style of adaptive retraces that are coming in to play.
For some applications however you really don't need or want DirectX/OGL.. Simple software based rendering is absolutely fine and apart from the legacy DirectDraw there is no "standard" way to detect a retrace.
Using these two DWM functions (from my research) seems to be the only possibly viable option to setup some sort of software timer that is in some way synchronised to the hardware event,
I'm assuming we would want to setup a thread which sleeps and fires up at a set point in time derived from the refresh rate into and qpcVBlank counter value.
I'll bet drunk people never even notice it,...:bgrin:
Then there was this...
https://msdn.microsoft.com/en-us/library/windows/hardware/ff548441(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/ff548441(v=vs.85).aspx)
https://msdn.microsoft.com/en-us/library/windows/hardware/ff548121(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/ff548121(v=vs.85).aspx)
https://gist.github.com/anonymous/4397e4909c524c939bee (https://gist.github.com/anonymous/4397e4909c524c939bee)
I wonder if that needs to be in a driver to make the kernel mode thunk or if you can call it from user land..
To be honest, I haven't found any information anywhere.
My only suggestion is to check the developer sections of the major graphics chipset manufacturers:
AMD Developer Central (http://developer.amd.com/)
NVIDIA Developer (https://developer.nvidia.com/)
...And, if you REALLY want to drive yourself nuts,...check this:
Ke-Sen Huang's Home Page (http://kesen.realtimerendering.com/)
That page contains links to all the SIGGRAPH, Eurographics, IEEE, and ACM graphics papers available on the Internet,...
They make for some pretty obtuse, abstract reading, though,...:bgrin:
https://code.google.com/p/chromium/issues/detail?id=467617 (https://code.google.com/p/chromium/issues/detail?id=467617)
I've got the functions calling from a test app, but for some reason they give me back an NTSTATUS error code of Invalid parameter (0xc000000d).
JOHNSA,
As you well know,...these are such extremely small time intervals that they are in the range of the time it takes to execute the instructions to detect it.
If you figure it out,...we should probably give you a genius award,...:bgrin:
...If it was me, I would try to find a way to skip the draw call which occurs during the moment of the Retrace. The frame frequency varies, though, depending on the code pipeline structure. Maybe, you should consult a quantum mechanics physicist,...:bgrin:
Success!
invoke CreateDC,NULL,CStr("\\.\DISPLAY1"),NULL,NULL
lea rcx,adapterInfo
mov [rcx],rax
invoke D3DKMTOpenAdapterFromHdc, rcx
and then...
lea rcx,adapterInfo
lea rdx,vblankInfo
mov eax,[rcx+8]
mov [rdx],eax
mov eax,[rcx+20]
mov [rdx+8],eax
invoke D3DKMTWaitForVerticalBlankEvent, rdx
... 60fps.. perfectly synced, no jitter or dropped frames.. now to code some Windows copper effects ;)
That github sample doesn't release the DC nor close the adapter (https://msdn.microsoft.com/en-us/library/windows/hardware/ff546787(v=vs.85).aspx) when its done. Those are things that are important to do.
You probably have them, but just in case.
Nice, didn't know this D3DKMT_WAITFORVERTICALBLANKEVENT function.
Can't wait to see your copper effects. :t
FWIW,
I don't get any "tearing" when blting from hDCMem (back frame) to the front hDC (Device Context). My programs produce frames at a rate from 7 ms (faster than the 60 FPS refresh rate) to over 100 ms, the blting operation takes a couple milliseconds I think. When I first was doing this I assumed I'd have to synch with the screen refesh, but in fact I don't. I had been supposing Windows was taking care of it for me, but this thread implies otherwise. You may be thinking a possible explanation is:
Quote from: Zen on July 14, 2015, 06:28:33 AM
I'll bet drunk people never even notice it,...:bgrin:
- but I can assure you, that's not the explanation! - because many non-drunk people* have also stared at it for hours - there is never any "tearing" or any such artifact. BTW I have seen lots of this problem in the old days (with CRT phosphor monitors); and also when I was drawing directly to the front frame; so I know what it looks like. I usually use an i5 with 4 cores, but the problem also never occurs on much slower computers, such as Pentium using 1 core.
FWIW.
* including young people with sharper eyes - altho admittedly only for minutes, their attention spans are much shorter
I've included a releasedc and closeadapter call in my code, good spotting!
I can't really explain why you wouldn't get tearing, my software blitting/rendering code generally runs at up to 500fps at 1920x1080 with some basic fills/screen clears etc. And 500fps simply HAS to tear although as you say I generally don't notice it (as in seeing visible tears in the screen). That said however what I do find is what the browser people refer to as "jank" where you get occasional stutters and dropped frames.
My suspicion would be if you're doing software rendering/blitting and are running at least Vista.. that the DWM(Desktop Window Manager) already only composites the windows and presents them at vblank, so you won't see tearing but what you would get is dropped frames.
Are you running Vista+ ?
It seems that in GDI it is not an easy way to get vert sync. Nevertheless, the main point is don't try drawing wildly, don't draw the same point more than one time in the same frame. In many cases using buffers may help. Another point is to achieve joining the path, for example when you draw a rotating image, in other case, bleep will occur whether you achieve vertical sync or not.
A tiny example of copperbars in GDI.
You can prevent jerky animations if you calculate a "smooth factor".
Calculate the time between the new and last vertical blank, and use that value to multiply with your animation update speed.
See the RenderD3D proc ( you can find it in Common\Direct3D9_Main.Asm), where I calculate the FrameTimeDelta.
See the Update_frame proc in 3D_colormap.Asm where I use the FrameTimeDelta (smooth factor) to update the cube rotation.
And see, no jerky animation.
Marinus
I always use a frame time delta to control animations (mainly to get it frame rate independent). But if you try and do this in software rendering (without D3D etc) i always find you get the occasional stutter..
a really classic example would be a scroller.. in the old vga days (ignoring the fact that we'd use unchained mode and latch transfers and true h/w page flipping and all the other cool stuff) you could have a full screen scroller that was 100% "smooth scrolling". I'm trying to be able to get the same degree of smoothness with s/w rendering under windows (if possible) and I think this retrace sync is the key. A long time ago even with retrace it wasn't possible under windows because context switches and things that happened even while using directdraw caused stutters.. I had a couple platformer games built with ddraw, and they always had the same issue...
smooth..smooth..smooth.. glitch... smooth..smooth..glitch while scrolling.
It looks to me thus far that these days that isn't the case because of the overall system performance and improvements in the scheduling, context switching etc that the delays are so small that it shouldn't affect a full frame (assuming you're not running a load of other cpu hungry stuff in the background).
QuoteI'm trying to be able to get the same degree of smoothness with s/w rendering under windows (if possible) and I think this retrace sync is the key.
I don't think so. The only way to get 100 % smooth animation, is on a non-multitasking OS where only your program is running.
On a multitasking OS the only thing you can do to get the best "smoothness", is using the frame time delta.
And it doesn't matter if you wait for the vertical blank or not on a multitasking OS.
It's always a good thing to use double frame buffering and wait for the vertical blank interrupt to prevent "tearing".
Just a little demo..
Requires 64bit+avx, must run on primary monitor @ 1920x1080.
The checkerboard is "copper" generated
you can use the mouse to move it around..
The background copper bars are generated in a "fake mode" (similar fashion to Panic or 2nd Reality pseudo 15bit plasmas from the old Dos demo days) by creating 2 interlaced images and flipping them quickly and combining R/G/Bs.
2 reasons for doing it this way... 1... it's cool... and 2 ... because of the flipping and selection of colors ANY dropped frame is extremely visible to the human eye.
FPS in the top left corner.. startups with new spiffy vsync timer+rasterline timing on (so you'll see 60/61fps).
INSERT key toggles vsync/rastersync on/off.
With it off you'll see the FPS doubles (about 140fps for me).
All animations are time-delta based, so regardless of FPS for example it takes 5 seconds for the red raster bar to make full cos cycle.
this is totally un-optimised and single threaded.. I could make it a lot faster, but it doesn't need to be for the quick example.
What you'll notice, and this is the point i was trying to make.. is how much better everything is with vsync on, smoother animation (due to no dropped frames).
I've figured the way it works in windows if you're doing soft-rendering is that the DWM composites are already vsync'ed, whether you like it or not (which is why you don't see tearing), BUT it will only process 60 frames per second and will drop others, which can be intermittent depending on how the timing all works out..
For example.. if you quickly drew a red then green screen in succession..and you were getting 100fps.. you might land up with a frame sequence like:
red, green, red, red, green ..
Can't test it, my monitor has a max. resolution of 1680 X 1050.
My bad,
I've attached a new zip with both 1920x1080 and 1680x1050 versions.
(Oddly for me the 1680 version does stutter now and then, perhaps because that's not my monitors native resolution but the 1920 is smooth smooth).
Both versions crashed on my computer....
Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz
Windows 8.1 64bit and AVX
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.
johnsa, your program hung both my machines ... had to actually unplug, task manager was useless on one machine, the other, it wouldn't even come up. Impressive! I manage to hang them up like that once in a while also, but I'm a seasoned expert, and even I can't do it so reliably. My hat is off to you! BTW b4 it crapped out totally the debugger showed the line "mov qword ptr [rsi], rax", C00000005. Probably rsi had a 0 in it, but couldn't check that.
But seriously - I have problems like this often (as you'll see if you check past threads) something works fine on my machine but not on others'. And it seems to happen a lot more with 64-bit. Found out recently that if I take the source code to the other machine and re-compile there, it often fixes the problem. Would love to know how to avoid it.
Have a question, you mention DWM is already v-synced (which I supposed), "BUT it will only process 60 frames per second and will drop others, which can be intermittent depending on how the timing all works out..". Now, if you're producing more than 60 FPS it's inevitable there will be dropped frames - regardless of DWM or anything else - right? There's simply no point in making frames faster than that. Or am I missing something here?
siekmanski, both your progs work fine. Both perfectly smooth. (BTW glad to see you're back to programming after goofing off for weeks :biggrin: )
Siekmanksi: I assume you're using D3D for your demo apps?
If so I believe the situation with hardware accelerated api's and software rendering with BitBlt type operations are quite different in this regard.
I myself have never noticed dropped frames when using ogl/d3d etc but i have seen tearing when the step sizes are large.
With software I've not seen tearing but you do get stutters.
So my belief is that due to how the gpu works and it's proximity to the framebuffer and lack of any windows compositing manager in the way it will (much like in the old vga/dos days) simply push out frames as fast as it gets it.. if the monitor happens to be half way through a draw.. tough luck you'll tear.
Software I suspect however is all being forced through the OSes normal window manager (DWM in this case with compositing) and this is internally v-synced. Making calls to StretchDiBits for example or others probably then feed data to the OS, which then drops it because it's already in the middle of a frame as it has no capability to "tear" a software buffer.
I think dropped frames is the only possibly way it can work in software if there is any part of the chain that limits the frame rate (via vsync or any other method). Unless you had an infinite queue so frames were always taken in order!
On a gpu based app, the only reasons i can see to NOT limit to vsync is that due to how vsync works, if you slightly miss it (15ms per frame) you can't get 55fps for example, it has to wait another full cycle and drop to 30fps.. which for gamers wouldn't be great. So I think the preference is to be able to achieve values between 30fps and 60fps in a game, even if it means tearing.
If you have a high enough spec and you know empirically that you always get way over 60fps, you could enable vsync on the gpu to remove the tearing.
Of course this is all starting to change now with adaptive v-sync, like gsync etc where the monitor only refreshes when it's told to .. so it's not technically running at 60hz but rather what ever the app requires.
I see that it does indeed bomb out completely on both another win8 and win7 machine but is fine on mine.
I'll try to see what is causing it.
Try this:
@ rrr314159
Quote(BTW glad to see you're back to programming after goofing off for weeks :biggrin: )
Hahaha... started this week with the FFT again, had some ideas for the first 2 log2 loops.
But your trick is smarter and faster than mine. Have some more ideas to improve speed.
@ johnsa
Yes, I'm using D3D9.
Maybe some other solution in software rendering is using more then one backbuffer, to average the stutter.
Although I'm not sure...
Your demo works fine now on my computer. But it's jerky.
For interest sake, before running the exe, try pressing Windows-D to minimize all open windows then run it and see if that makes any difference.
I assume it's jerky by default with the fps at 60 ? (I expect it be very jerky after pressing INSERT and having 100+ fps due to the dropped frames).
Closing all windows makes a big difference, it's much smoother. ( now and then a stutter )
Did you have a look at my FrameTimeDelta code ?
Maybe we do it both differently, you could try my code.
You could also use D3D9 to do 2D stuff and write directly to the backbuffer or a rendersurface.
I'm still trying to work out why having other windows not minimized sometimes affects the vsync/stutter... it only does it now and then for me, but a win-d switch back seems to sort it out.
I normally use webgl or dx11, but this is all about non-gpu experimenting otherwise the whole vsync would have been a non-issue in the first place! :)
My delta is basically :
; For a full cos / sin cycle:
delta = (6.2832 / (FPS * secondsToAnimate) )
so if it's 60fps, and I want the animation sequence to run for 10sec, 6.2822 / 600 = 0.06deg per frame to complete the full cycle in 10 seconds. FPS is calculated each frame as 1000 / (endMs - startMs)
I just calculate the time between the previous and the current frame, and use that as a smoothing factor.
It is just multiplied with whatever update speed you use. So the actual animation step is totally smooth.
See my VSyncOFF.exe example and see how the frame rate varies but the animation still runs smooth
johnsa,
that version works fine. There's some stutter (I think that's what it's called). The front object in particular, when moving fastest, shows about 5 borders at once (the edge is indistinct), closely spaced. Happens a little on the checkerboard also. Minimizing other windows, also insert key, make little or no difference. Looks pretty good, not perfect
Quote from: Siekmanski on July 15, 2015, 10:11:46 AM
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 ::)
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.
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.
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.
Quote from: jj2007 on July 15, 2015, 12:11:18 PM
Quote from: Siekmanski on July 15, 2015, 10:11:46 AM
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.
Quote from: johnsa on July 15, 2015, 06:50:21 PM
Quote from: jj2007 on July 15, 2015, 12:11:18 PM
Quote from: Siekmanski on July 15, 2015, 10:11:46 AM
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 ?
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.
It runs very smooth.
What causes the stutters ?
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.
Quote from: Siekmanski on July 15, 2015, 07:38:34 PMThe 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.
@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.
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 :)
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.