Symptoms

Calling the acquisition start function (syntax depending on the used programming language) takes longer than expected. Especially the first time after the resulting image buffer layout has been changed / the buffer size did increase after applying various changes.

Cause

The internal acquisition engine does not allocate memory until it is actually needed which usually is upon calling acquisitionStart for the first time after applying changes affecting (increasing) the resulting buffer e.g. due to AOI changes. This memory allocation time is only consumed when an application doesn't provide it's own custom memory (see the CaptureToUserMemory example for the programming language of your choice).

Also the mapping of the virtual addresses of the pages forming the full buffer to physical ones inside the device driver does only happen once per buffer if the buffer layout stays the same in between acquisition loops in order to save time.

Both operations are expensive in terms of time consumption for time sensitive applications thus are reduced to a minimum but can still be annoying under certain circumstances.

Resolution

Once acquisitionStart is called, the internal buffer management needs to allocate the required memory for all buffers before the acquisition engine can start. Since last minute modifications might change the buffer layout it doesn't make too much sense to do this earlier. Afterwards the buffers must be mapped in kernel space to allow zero copy transfer. Especially this mapping takes time and this time directly relates to the number of request objects queued before starting the acquisition and the size of each request buffer.

Two things can be done to reduce the time needed to start the acquisition engine. Both approaches may be combined to achieve optimal performance:

Pre-Allocation Of Buffers

This will eliminate the extra time needed to start the acquisition the first time after changing the buffer layout!

Configure the camera to the maximum possible AOI and fill the request queue by calling imageRequestSingle as many times as request objects are specified by the requestCount property. The acquisition engine will allocate the required memory for each request object. Then start and stop the acquisition engine and unlock all request objects afterwards and adjust all settings as required for the 'real' application.

Note

This procedure will only work within the same process and only until any existing Impact Acquire instance is closed within this process. Once an existing connection to a device has been closed this has to be repeated the next time it shall be used!

Don't Queue All Requests Before Starting The Acquisition

Since additional buffers can be queued at any time a significant speedup can be achieved by queueing less requests before starting the acquisition. If not needed it might be a good idea to work with less request objects anyway to reduce the overall memory footprint of the application. However if e.g. 10 request are needed a speedup can be achieved by queueing e.g. 3 requests, then call acquisition start and then queue the remaining requests before starting to wait for the first image to become ready.