Red Hat Bugzilla – Bug 1006984
Cropping is very slow in simple-scan 3.8.0 (regression)
Last modified: 2014-03-12 09:17:39 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.
Resizing the cropping an image should not hang the application.
It seems there is a fix upstream (see the Launchpad bug page).
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
Confirmed I have the same exact issue in 184.108.40.206.fc20.
The mount workaround is a life-saver!
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.
I didn't do much testing but choose the workaround as suggested in https://bugs.launchpad.net/simple-scan/+bug/1245678 to disable autosave:
chmod 500 ~/.cache/simple-scan/autosaves
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.