With the planned support for multiple monitors, nitpicker's existing approach of operating at a fixed period is no longer satisfactory. When anticipating multiple monitors each with a different refresh rate, or a display with a variable refresh rate, nitpicker must become a mere broker between the activities of capture clients (display drivers calling capture_at and eventually capture_stopped) and GUI clients (applications receiving a sync signal whenever content was captured).
This change breaks the current assumption of applications that sync signals are unconditionally delivered at fixed intervals and thereby can be used as time source. With the change to a mere event-driven operation, applications must base their timing on an actual time source (like a timer session) and expect sync signals to stop occurring after a period of inactivity (the time until a display driver stops capturing, which should be around 50 ms).
With the planned support for multiple monitors, nitpicker's existing approach of operating at a fixed period is no longer satisfactory. When anticipating multiple monitors each with a different refresh rate, or a display with a variable refresh rate, nitpicker must become a mere broker between the activities of capture clients (display drivers calling capture_at and eventually capture_stopped) and GUI clients (applications receiving a sync signal whenever content was captured).
This change breaks the current assumption of applications that sync signals are unconditionally delivered at fixed intervals and thereby can be used as time source. With the change to a mere event-driven operation, applications must base their timing on an actual time source (like a timer session) and expect sync signals to stop occurring after a period of inactivity (the time until a display driver stops capturing, which should be around 50 ms).