Improve Realtime Graph Latency

[planetchili]

Currently the monitoring/graphing of metrics and frame event data (typically via the overlay) has a hard limit of 1 second of latency. This is the because ETW batches events together, invoking the callback in bursts at an interval of 1 sec.

Understandably, the user experience suffers because of this, and it also complicates some aspects of metric processing.

It appears to be possible to manually flush the trace buffers with by using a FLUSH control command. Therefore, it should be possible to achieve latencies order(s) of magnitude lower than we currently have.

[planetchili]

Tasks

• [x] Create minimal POC and verify cadence of ETW event callbacks
• [x] Verify the integrity of event reporting (no regressions in lost buffers/events)
• [x] Integrate a FLUSH controller thread into PresentData
• [x] Verify and fix compatibility with Service
• [x] Verify and adjust compatibility with Middleware / AppCef (verify that latency reduction is achieved)
• [x] Implement options to control flush interval (initially via Service CLI)
• [ ] Ensure backwards compatibility / migration of preferences files with new settings
• [ ] Hide advanced timing settings behind CLI option and determine default behaviors
• [ ] Survey the perf impact of different FLUSH intervals and determine a "sweet spot" to default to
• [ ] Adjust default AppCef / Middleware behavior to match the default flush interval

[planetchili]

Ask Microsoft around faster manual polling rate in ETW. Ask about overlay stuff while we're at it.