Diagnose machine vision screen tearing in live previews

A live preview can show horizontal breaks even when the camera delivers complete images. Similar-looking stripes can also originate in captured data, conversion code or buffers being overwritten during display. This troubleshooting workflow is for engineers separating those faults before replacing hardware. You will compare saved frames with the preview, isolate acquisition from rendering, and measure queue behavior without confusing smooth animation with low latency.

Identify the artifact before changing settings

True display tearing occurs when one screen refresh contains portions of different presented frames. A moving edge appears displaced across a horizontal boundary. The boundary may move between refreshes, and the complete source images can remain intact.

However, a horizontal line is not enough to diagnose tearing. Start by classifying what you see.

If delay is the main symptom rather than split imagery, use the separate fullscreen preview lag diagnostic. Reducing latency and preventing tearing are related engineering tasks, but they require different measurements.

Separate captured frames from the display path

The highest-value test is to preserve an image before the preview renderer touches it. A screenshot does not provide that separation: it records some part of the desktop presentation path, not necessarily the camera buffer.

1. Use a repeatable scene. Include a stationary textured background and a moving edge. Keep exposure, gain, image size and acquisition rate unchanged between tests.
2. Save a small diagnostic sample. Copy each selected completed acquisition buffer into application-owned storage. Preserve frame identifiers, timestamps, dimensions, pixel format and row stride where available.
3. Inspect the saved images independently. Open them as still images through a different viewing path. Where supported, retain the original pixel payload alongside any converted image.
4. Compare corresponding frames. Check whether the same displaced edge, band or corrupted row exists in the saved image, rather than merely somewhere in the preview.
5. Repeat with preview updates disabled. Continue acquisition and logging. This reveals whether display work contributes to missing or damaged frames.

Keep the saving operation short and bounded. Writing every frame to storage can introduce a new bottleneck, making the diagnostic change the failure.

A preview that becomes clean when paused is suggestive, not conclusive. Pausing also removes motion and changes buffer access. A saved, independently owned frame provides stronger evidence.

Run acquisition-only and rendering-only tests

Once you have a trustworthy saved frame, split the application into two controlled workloads.

For the acquisition-only test, disable image display while retaining capture counters and error reporting. Compare delivered frame counts, incomplete-frame reports and processing time with the original application. If acquisition improves, rendering or resource contention is affecting the pipeline; that does not automatically mean the camera is faulty.

For the rendering-only test, disconnect the live acquisition path from the viewer. Animate a simple moving bar or replay complete, owned images through the same rendering code. Reproducing the split without live capture places the problem downstream of acquisition.

Also compare a basic viewer with the affected application while keeping the camera configuration constant. A clean alternative viewer makes an application-specific fault more likely, but viewers can request different image formats, rates or buffering policies. Confirm those settings before drawing conclusions.

If frames disappear only under combined load, follow the dropped-frame isolation workflow. Separate transport loss, application discard and skipped preview updates in the counters; they are not interchangeable events.

Check buffer ownership before adjusting refresh settings

An application can create a torn-looking image even when display presentation is synchronized. This happens when one thread reads an image while another overwrites its pixels.

Many acquisition interfaces lend buffers to the application temporarily. After a buffer is released or requeued, its contents may change. Holding a reference to that memory is not necessarily the same as owning a stable image.

Check the following points:

• Completion: consume a buffer only after acquisition reports it complete.
• Lifetime: do not release or requeue it before all readers have finished.
• Ownership: create an owned copy when the renderer must outlive the acquisition callback.
• Handoff: publish a complete image reference atomically or through a properly synchronized queue.
• Upload completion: keep source memory valid until the graphics API no longer needs it.
• Layout: use the reported row stride and pixel format instead of assuming tightly packed rows.

A bounded latest-frame slot is often appropriate for a preview. Acquisition publishes a complete new image, while the renderer retains its own reference to the image currently being displayed. Replacing the slot must not overwrite memory still in use.

This preview policy must remain separate from inspection processing. Skipping an obsolete display frame can be acceptable; silently skipping a required inspection frame is not.

For application-wide frame identity problems, use timestamp and frame matching checks rather than relying on window appearance alone.

Measure frame age and queue growth

Acquisition rate, display refresh rate and preview consumption rate are different quantities. A rate mismatch can produce repeated frames or uneven motion without necessarily producing tearing.

For example, a camera producing 30 frames/s has a nominal frame interval of about 33.3 ms. A display refreshing at 60 Hz has a refresh interval of about 16.7 ms. Repeating each image across two refreshes can be perfectly clean when presentation is coordinated with scanout.

Consider a preview receiving 30 frames/s but consuming only 20 frames/s. If every frame is retained, the backlog grows by:

That queue can create substantial delay even if every displayed image is visually complete. Increasing buffer capacity hides the overload longer; it does not correct it.

Log frame age at presentation as well as queue depth. Calculate age only from timestamps sharing a timebase or from clocks whose relationship has been established. Subtracting an unsynchronized camera timestamp from a host timestamp can produce misleading values.

If host arrival times vary while camera timestamps remain regular, investigate transport and scheduling separately with the frame-arrival jitter diagnostic.

Test the presentation path with one change at a time

When owned images are clean and rendering-only animation reproduces the fault, investigate presentation settings before changing acquisition hardware.

First, check whether presentation is synchronized to the display refresh. The relevant setting may belong to the application, graphics API, window compositor or display driver. Enabling synchronization can remove scanout tearing, but additional buffering may increase latency. Verify both image continuity and frame age after the change.

Next, compare windowed and fullscreen presentation while holding the workload constant. Different paths can use different compositing and synchronization behavior. A change in appearance identifies a useful boundary; it does not establish a universal preference for either mode.

Then reduce the display workload without changing acquisition. Resize the preview or display a reduced-resolution copy while preserving the original inspection image. If this changes the symptom, measure conversion, upload and rendering time independently. The responsive image-display ROI guide explains how to separate viewing needs from processing data.

Finally, inspect graphics initialization logs. A context-creation or authentication warning deserves investigation, but it does not prove the source of every visible artifact. Confirm the loaded graphics runtime and supported driver combination using official documentation and packages.

If saved images contain the fault, move upstream

When the artifact survives in an independently owned saved image, display synchronization is not the first repair target. Find the earliest processing stage where it appears.

Compare the original payload with the converted image. Incorrect row stride, packed-pixel interpretation or image dimensions can produce repeated bands and displaced rows. A correct grayscale view does not prove that every color-conversion path uses the right layout.

Check acquisition status for incomplete buffers and transport errors. For intermittent scrambled rows or unrelated image fragments, use the captured-frame corruption diagnostic.

Also distinguish corruption from scene-dependent effects. Periodic illumination can produce bands, while sequential sensor readout can distort moving objects. Compare a stationary target under steady illumination, then vary motion separately. Do not change exposure, lighting and transport settings together: that removes the evidence needed to identify the cause.

A text-based or alternate display is not automatically independent evidence. It may share the same acquisition buffers, conversion code or terminal redraw limitations. Independence comes from the data path, not the visual style.

Choose hardware only after locating the failure

Replacing the camera will not repair an unsynchronized presentation path. Likewise, a faster host will not correct an invalid buffer lifetime. Treat hardware selection as a separate decision supported by the isolation tests.

If a planned comparison requires a different acquisition interface, browse area scan cameras through the camera finder. Compare shutter behavior, image format, sustained throughput and software support before selecting a substitute.

The LS-CMR-0053 is a catalog example for evaluating a GigE acquisition path. It is not a prescribed fix for display tearing.

The LS-CMR-0166 provides a USB3 catalog example for interface planning. Changing interface also changes the acquisition path, so document that difference in any comparison.

When selecting vision controllers, confirm the intended display connection, supported graphics runtime and measured application workload. Camera connectivity alone does not establish preview performance. Ask for evidence using the actual image dimensions, conversion steps and display arrangement rather than relying on processor labels.

Verify the repair and record the configuration

A successful repair produces complete displayed images without allowing frame age or inspection losses to grow. Repeat the original failing workload and retain the same motion target, image settings and logging method.

Use this acceptance checklist:

• [ ] Independently saved frames are free of the reported artifact.
• [ ] Moving edges remain continuous during live presentation.
• [ ] Frame age stays bounded rather than increasing throughout the run.
• [ ] Acquisition, inspection and preview counters have separately defined meanings.
• [ ] Required inspection frames are not discarded by the preview policy.
• [ ] Image buffers remain valid until acquisition and rendering consumers finish.
• [ ] The application behaves consistently after a normal restart.
• [ ] The working driver, runtime and presentation settings are documented.

Set the duration and allowable latency from your process requirements. A brief visual check cannot establish long-run queue stability, and a smooth preview cannot establish inspection completeness.

For help reviewing the evidence, send a concise symptom description, representative saved frames and timing logs through application support. If the diagnosis establishes a genuine camera requirement, use the camera configurator with the measured image size, frame rate and interface constraints.