Bug 1006984 - Cropping is very slow in simple-scan 3.8.0 (regression)
Summary: Cropping is very slow in simple-scan 3.8.0 (regression)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: simple-scan
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David King
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-11 16:11 UTC by Rémi G.
Modified: 2014-03-12 13:17 UTC (History)
9 users (show)

Fixed In Version: simple-scan-3.10.2-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-12 13:17:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1121169 0 None None None Never

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


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