#1389 NAPS2 8.5.1 – 7–8 Second TWAIN Initialization Delay with Fujitsu fi-7280 (Every Scan)

[Louis Martino]

Hello,

I am experiencing a consistent 7–8 second delay every time I initiate a new scan using NAPS2 8.5.1 with my Fujitsu fi-7280 and PaperStream IP TWAIN driver.

The scanner otherwise works reliably, but this initialization delay occurs before every individual scanning job, even when NAPS2 is already running and multiple consecutive scans are performed.

System Configuration

• Operating System: Windows 11 (64-bit)
• Scanner: Fujitsu fi-7280 (ADF and flatbed)
• Scanner Firmware: 0510
• Connection: USB
• NAPS2 Version: 8.5.1
• Scanner Driver: PaperStream IP (TWAIN) 3.40.2.1815
• TWAIN Implementation: Default (New DSM)
• Use Native UI: Enabled
• PaperStream ClickScan: Version 1.6.2.1

Description of the Problem

When I press the physical Scan button on my scanner or click Scan within NAPS2, approximately 7–8 seconds pass before the PaperStream native interface becomes available.

When using the physical scanner button, scanning starts automatically after this delay.

When using NAPS2's Scan button, I manually press Scan in the PaperStream interface after it appears. Scanning then begins immediately.

Once scanning starts, the scanner operates normally.

If I place 10 pages in the ADF, there is one initial 7–8 second delay, followed by normal continuous scanning of all 10 pages.

However, after that scanning job completes, initiating another scan immediately produces the same 7–8 second delay.

This behavior is consistent and reproducible.

Important Comparison with PaperStream ClickScan

This startup delay does not occur when I use Ricoh/Fujitsu's PaperStream ClickScan software.

The scanner begins scanning promptly with ClickScan, but NAPS2 consistently experiences the delay.

Because both applications use the same scanner, I am interested in understanding whether NAPS2's TWAIN initialization process contributes to the difference.

I strongly prefer NAPS2's scanning and PDF workflow and would like to continue using it.

Debug Log Findings

I enabled NAPS2 debug logging and examined the timestamps.

The following entries illustrate where the delay occurs:

18:37:24.2326 Scanning with ScanDevice
18:37:24.7851 Debug: Using new dsm.
18:37:24.9250 Using TWAIN DSM: C:\Program Files\NAPS2\lib\_win32\twaindsm.dll
18:37:24.9337 NAPS2.TW - Opening session
18:37:24.9337 Debug: Thread 2: OpenManager.
18:37:26.7994 NAPS2.TW - StateChanged (to 3)
18:37:26.8073 Debug: Source id = 1
18:37:26.8365 Debug: Thread 2: OpenSource.
18:37:28.0060 NAPS2.TW - StateChanged (to 4)
18:37:28.0504 NAPS2.TW - Enabling source
18:37:28.0504 Debug: Thread 2: EnableSource with ShowUI.
18:37:31.1887 NAPS2.TW - StateChanged (to 5)

Based on these timestamps:

• Initial scan request to TWAIN session opening: approximately 0.70 seconds
• Opening TWAIN manager: approximately 1.87 seconds
• Opening scanner source: approximately 1.20 seconds
• Enabling the TWAIN source with native UI: approximately 3.14 seconds
• Total time from initial request to TWAIN state 5: approximately 6.96 seconds

This closely matches the observed 7–8 second delay.

I can provide the complete debug log for further examination.

Troubleshooting Already Performed

1. Tested the Default TWAIN implementation. Scanning works, but the delay remains.
2. Tested Old DSM. There was no meaningful improvement, so I returned to Default.
3. Performed repeated consecutive scans. The delay occurs before every new scanning job.
4. Tested scanning multiple pages through the ADF. Pages scan normally after the initial delay, confirming that the problem is not per-page scanning performance.
5. Tested the scanner's Manual-feed timeout feature. This allowed additional sheets to be scanned within the same session, but caused repeated roller activity, audible alerts, and an unacceptable delay before the job could finish. I disabled this feature again.
6. Confirmed that PaperStream ClickScan does not exhibit the same noticeable startup delay.

I have not changed or replaced the working scanner driver.

Possible TWAIN Session Initialization Issue

While researching the NAPS2 source code, I examined RemoteTwainController.cs, particularly the way a TWAIN worker context is created for a scanning operation and disposed of afterward.

I am wondering whether initializing a new worker, TWAIN manager, and scanner source for each scan contributes to the delay.

I understand that TWAIN session management involves compatibility, resource cleanup, threading, and device-locking considerations.

Nevertheless, I would appreciate your assessment of whether an initialized TWAIN worker or TWAIN manager/source could be reused between separate scanning jobs, without requiring the scanner to remain in an active paper-feeding state.

Questions / Requested Assistance

1. Is this repeated 7–8 second initialization expected for PaperStream TWAIN devices when used through NAPS2?
2. Does NAPS2 intentionally reopen the TWAIN manager and scanner source for every new scanning job?
3. Is there an existing setting or supported optimization that could reduce this delay?
4. Could reusing a TWAIN worker process or maintaining a persistent TWAIN session improve performance?
5. Would additional debug instrumentation help identify which initialization steps are responsible?
6. If this cannot currently be resolved through configuration, would you consider an enhancement to improve TWAIN initialization performance?

Desired Outcome

I would like to retain all of NAPS2's functionality, including the full PaperStream native scanning interface, OCR, PDF creation, and support for the physical scanner Scan button.

My goal is simply to reduce or eliminate the 7–8 second delay that occurs before every scanning job, without compromising scanner reliability or requiring a waiting period after the final page.

I would be happy to perform additional controlled tests and provide further diagnostic information.

Thank you for developing NAPS2 and for any assistance you can provide.

Best regards,

Louis Martino