Update:
It is confirmed that “strange” increase in latency of full capturing/rendering sequence at higher framerates is only due to rendering inefficiencies/limitations (and not capturing) of rendering/display subsystem as well as restrictions related to syncing of rendering with native display refresh rate (at least on Windows/Direct3D and threading limitations).
Not going too deep into problems of updating with exactly speed of VSYNC and related to polling VSYNC on Windows, I’ll just report that as the result of my optimization efforts in rendering implementation of DirectShow Filter, I’m now managing to fullys sync Direct3D rendering at 60FPS with simultaneous capturing at the same 60FPS on LCD system configure at 75FPS refresh rate. There are no visible dropage in captured/rendered frames and I’m getting the following reslts in latency:
640*480 at 60FPS: Full capture/render latency: ~49.5ms (3frames) Capturing/DS Transport: ~40ms Rendering: 9.5ms CPU24-25%
320*240 at 60FPS: Full capture/render latency: ~50.5ms (3frames) Capturing/DS Transport: ~45ms Rendering: 5.5ms CPU10-12%
CPU date includes measuring overhead.
I would also suspect, that moving away from DirectShow to processing using just pure Direct3D and considering above latency data of just capturing published by Alex (shoebox test) might be improved by max 1 frame, due to rendering restrictions that are not DirectShow related, but in fact are restrictions of rendering windows (possibly other OS) subsystem. Even without DirectShow someone will be faced with the same problem of performing video update exactly with the refresh rate of video subsystem.