Bug 1006984 - Cropping is very slow in simple-scan 3.8.0 (regression)
Cropping is very slow in simple-scan 3.8.0 (regression)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: simple-scan (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David King
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2014-03-12 09:17:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):
simple-scan-3.8.0-1.fc19

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:

https://bugs.launchpad.net/simple-scan/+bug/1121169

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 3.10.0.1.fc20.
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:

http://bazaar.launchpad.net/~simple-scan-team/simple-scan/3.10/revision/644

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

https://admin.fedoraproject.org/updates/FEDORA-2014-3721/simple-scan-3.10.2-1.fc20
https://admin.fedoraproject.org/updates/FEDORA-2014-3722/simple-scan-3.10.2-1.fc19

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