Between-frame polling is suitable when the input remains active and the longest gap between checks meets your response limit. Timer scheduling helps share execution time, while brief pulses may need a separate capture path. Measure input detection and the resulting application action under the full playback workload.
Polling inputs during video can work if the input stays active long enough and the application returns to it within your response-time limit. A timer is useful when playback must share execution time with other work, but it does not automatically make input handling faster. Decide from the longest gap between input checks, the shortest valid input event, and the delay before the application actually changes state.
What between-frame polling does
In a simple application-controlled playback loop, the program prepares a frame, displays it, checks an input, and waits until another frame is due. The input check runs only when execution reaches that point.
This can suit an instructional video that should end when a maintained completion signal becomes active. It is less suitable for counting short sensor pulses or meeting a tight response deadline.
First establish what your playback interface allows. A function that plays an entire clip before returning does not provide an opportunity to insert checks between frames. You need a documented frame-stepping interface, a nonblocking playback interface, or an input task that can run independently. Inspect the examples supplied with the manufacturer's development software rather than assuming that a video layout object exposes scheduling controls.
Touch input also needs a distinction. Reading the current touch state is polling a level. Reading a buffered touch event retrieves an event that the input system has already captured. Their timing limits are different.
Work out the response limit
Write down the maximum acceptable delay from the input becoming valid to the required application action. Define the action precisely: recording the input, leaving the playback state, and displaying the next page are different milestones.
For a stable, already-conditioned input, use two timing quantities:
- G: the longest interval between consecutive input reads.
- A: the longest delay from a successful read to the required application action.
A transition just after a read can wait almost G before detection. A conservative response bound is therefore G + A, provided both quantities are genuine upper bounds under the intended workload.
For example, if G is bounded at 50 milliseconds and A at 10 milliseconds, their sum gives a 60-millisecond response bound. These are illustrative design values, not specifications for any display.
Include all work in the gap between reads: frame preparation, drawing, storage access, input handling, other application tasks, and deliberate waiting. Debounce or input filtering can add delay before the signal is considered valid. Account for that separately using the documented input behavior.
Average frame rate does not establish a response-time bound. At 25 frames per second, the nominal frame interval is 40 milliseconds, calculated as one second divided by 25. An occasional longer operation can still create a larger polling gap. The distinction matters when planning signage animation frame rate: smooth-looking playback and bounded input latency are separate requirements.
Why brief pulses are different
A maintained signal remains available for a later read. A pulse can become active and return inactive entirely between two reads. In that case, polling the current level provides no evidence that it happened.
In an ideal sampling model, a clean pulse that remains active longer than the maximum polling gap overlaps at least one read. A practical design also needs margin for input filtering, scheduling variation, and the hardware's minimum detectable pulse width. Do not choose the interval from the average pulse duration.
If valid events can be shorter than the gap, consider a documented capture method:
- A hardware latch that retains the event until acknowledged.
- An input counter or capture peripheral intended for that signal.
- An interrupt-driven event path with suitable buffering.
- A controller that captures the event and exposes a maintained application status.
These methods still have limits. Interrupt handling can be delayed, queues can fill, and counters have finite capacity. Check the manufacturer's documentation for the actual capture path rather than assuming an interrupt captures every event.
For buffered touch events, determine how long events are retained, whether order is preserved, and what happens when the application falls behind. Increasing the frequency of current-state reads does not replace a reliable event queue.
When timer scheduling helps
A scheduled design separates the question “Is a frame due?” from “Has the input changed?” Instead of waiting inside the playback loop, the application services input and advances video when its next deadline arrives.
| Approach | Useful when | Main limitation |
|---|---|---|
| Input read between frames | The signal is maintained and the longest polling gap meets the response limit | Long frame operations delay the next read |
| Timer or event-loop scheduling | Playback must share time with input handling and other application work | Blocking operations can still delay scheduled work |
| Independent input capture | Brief events must be retained regardless of frame timing | Capture hardware, buffering, and acknowledgment need defined limits |
A timer callback running on the same event loop cannot execute while that loop is blocked inside a long operation. A timer may mark a frame as due without making the frame draw happen immediately.
In embedded firmware, keep interrupt-context work short and follow the platform's documented restrictions. A timer can set a flag or wake a task; decoding video or drawing a complete frame inside the interrupt routine is generally the wrong place for lengthy work.
The useful change is bounded, nonblocking application work. Adding a timer to an otherwise blocking design does not supply that property by itself.
Keep input and playback states separate
Define the input's meaning before changing the playback loop. A completion signal, a request to advance, and a counted event require different handling.
Check whether the condition is already active before playback starts. Decide whether that should skip the video or whether the application requires a new event after entry. Do not rely on an accidental first-frame delay to determine the result.
Keep these application states distinct:
- Playing: frames are eligible to advance and the input condition is being evaluated.
- Completion accepted: the condition has been recognized and further frame requests are suppressed.
- Next page: the application has entered the intended destination.
- Clip finished normally: playback reached its end without the completion condition.
A captured event may need acknowledgment after it has been consumed. Define that handshake so an old event does not immediately end the next playback session, and a new event is not erased accidentally.
Do not simply shorten every frame pause to obtain faster input checks. In a loop paced by fixed delays, that also changes playback speed. Where supported, service input while waiting for the next frame deadline rather than altering the intended video timing.
Measure the complete response
Use a representative clip and the intended application workload. A stationary page does not exercise the same frame preparation and drawing paths.
Observe the input transition and the application response with suitable timestamped diagnostics or test equipment. Measure input detection separately from the visible page change. Logging itself can affect timing, so keep instrumentation lightweight and account for its overhead.
Group the checks by what they establish:
Timing coverage
- Apply the input near the beginning, middle, and end of playback.
- Vary its timing relative to frame preparation, drawing, and waiting.
- Exercise other application work that normally runs alongside video.
- Record the longest observed read gap and input-to-action delay, not just averages.
Event capture
- Test the shortest valid pulse specified for the application.
- Shift pulses across the polling interval rather than repeating them at one fixed phase.
- Exercise repeated events at the highest expected arrival rate.
- Check filtering, debounce, queue capacity, and acknowledgment behavior where applicable.
Application transitions
- Start playback with the condition already active.
- Confirm that accepting the condition leads to the correct destination.
- Confirm that surrounding application logic does not immediately restart the clip.
- Let the clip finish without an input and check its separate completion behavior.
- Exercise touch and external input together if both are part of the design.
The largest observed delay is evidence from that test, not proof of an absolute worst case. Combine measurements with documented timing limits and inspection of potentially blocking operations. If a strict deadline matters, establish a defensible upper bound rather than relying only on a successful demonstration.
Choose the design from the results
Use between-frame polling when the signal persists, the application exposes suitable execution points, and the bounded response fits the requirement with margin.
Use scheduled playback when input handling and other application tasks need more frequent service than the frame loop provides. Address long blocking operations as part of that change.
Use event capture when a valid pulse could disappear between reads. Faster video playback is not a dependable correction for missed events.
Keep this interaction separate from machine safety. Ending a video or changing a page is ordinary application behavior, not a protective stop. Safety-related inputs and actions need an appropriate machine safety design independent of video execution. The distinction between a factory status display and a control interface helps define that boundary before implementation.
Questions
Can an input be checked between video frames without a timer?
Yes, if the playback interface exposes between-frame execution points and the input remains active long enough. The longest interval between reads, plus the time needed to act on a detected input, must fit your response requirement. A function that blocks until the whole clip finishes needs a different playback or input-handling approach.
Does timer-driven playback provide faster input response?
Not necessarily. A timer callback on the same event loop can be delayed by blocking frame preparation or drawing. Timer scheduling helps when it allows short, bounded tasks to share execution time. Measure the resulting input latency instead of assuming that the presence of a timer establishes a response limit.
Why can polling miss a sensor pulse?
A pulse can start and finish between consecutive reads, leaving the same inactive level at both checks. Use the shortest valid pulse and the longest read gap when assessing this risk. If polling cannot meet the capture requirement, use a documented latch, counter, capture peripheral, or buffered event path appropriate to the hardware.
What should be measured during a playback input test?
Measure the longest interval between input reads, the delay from the physical input to detection, and the delay to the required application action. Include representative video and competing application work. Check short pulses, initially active inputs, normal clip completion, and transitions out of playback. Observed maxima alone do not establish an absolute worst-case bound.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.