Bug 1006984

Summary: Cropping is very slow in simple-scan 3.8.0 (regression)
Product: [Fedora] Fedora Reporter: Rémi G. <remjg>
Component: simple-scanAssignee: David King <amigadave>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: amigadave, bfay, emmanuel.touzery, eu, fcdanilo, jorge.fabregas, kelk1, metherid, west
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 13:17:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rémi G. 2013-09-11 16:11:45 UTC
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 16:28:33 UTC
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 22:54:14 UTC
Confirmed I have the same exact issue in 3.10.0.1.fc20.

Comment 3 Emmanuel Touzery 2014-01-12 12:13:50 UTC
The mount workaround is a life-saver!

Comment 4 Burnie West 2014-01-13 00:27:38 UTC
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-13 01:49:01 UTC
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 16:14:38 UTC
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 17:27:30 UTC
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 14:34:01 UTC
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