Bug 1006984 - Cropping is very slow in simple-scan 3.8.0 (regression)
Cropping is very slow in simple-scan 3.8.0 (regression)
Product: Fedora
Classification: Fedora
Component: simple-scan (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David King
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-09-11 12:11 EDT by Rémi G.
Modified: 2014-03-12 09:17 EDT (History)
9 users (show)

See Also:
Fixed In Version: simple-scan-3.10.2-1.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-12 09:17:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1121169 None None None Never

  None (edit)
Description Rémi G. 2013-09-11 12:11:45 EDT
Description of problem:
Cropping an image is very slow, it sometimes take 20 seconds to resize the cropping area which makes it unusable for this kind of tasks.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Scan an image
2. Crop the image and try resizing it
3. Simple-scan hangs, wait... maybe about 10 seconds.

Expected results:
Resizing the cropping an image should not hang the application.

Additional info:
It seems there is a fix upstream (see the Launchpad bug page).
Comment 1 Eric 2013-10-26 12:28:33 EDT
Looks like it is caused by a switch to sqlite3 and saving temporary states. Does not really seem fixed:


Last report from 2013-10-24: "Can confirm this bug on 3.10 as well: Scanning and cropping a photo is insanely slow."

The trick to mount the autosaves directory in tmpfs is quite a nice workaround. Before using simple-scan:

sudo mount -t tmpfs none ~/.cache/simple-scan/autosaves
Comment 2 Luis Verissimo 2013-12-10 17:54:14 EST
Confirmed I have the same exact issue in
Comment 3 Emmanuel Touzery 2014-01-12 07:13:50 EST
The mount workaround is a life-saver!
Comment 4 Burnie West 2014-01-12 19:27:38 EST
The behaviour remains; the workaround is barely tolerable. I've used simplescan for several multipage documents in the past; I would not find the workaround a reasonable addition to my workflow. If (as appears in bug 1121169) the purpose is to avoid losing work if simplescan crashes, then the appropriate fix is to avoid/eliminate the crash.
Comment 5 Danilo Câmara 2014-01-12 20:49:01 EST
I didn't do much testing but choose the workaround as suggested in https://bugs.launchpad.net/simple-scan/+bug/1245678 to disable autosave:

rm ~/.cache/simple-scan/autosaves/*
chmod 500 ~/.cache/simple-scan/autosaves
Comment 6 Jorge Fábregas 2014-03-08 11:14:38 EST
I ended up here while searching for the same problem.  I'm in F20 with the latest simple-scan-3.10.0-1.fc20.x86_64.   Please fix this.  I'm going to try the workarounds but for a new user this is really unacceptable (cropping is too crappy).

I think a new BZ should be generated for F20 as well.
Comment 7 Fedora Admin XMLRPC Client 2014-03-08 12:27:30 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 David King 2014-03-11 10:34:01 EDT
The latest version of simple-scan (3.10.2-1, currently in updates-testing) drops the SQLite dependency and should fix this bug:


I just tested it out, scanning some A4 pages and it seemed fine to me.


Note You need to log in before you can comment on or make changes to this bug.