Bug 238776

Summary: Node of curves stick to cursor
Product: [Applications] digikam Reporter: Simon <simon.eu>
Component: Plugin-Editor-CurvesAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 1.3.0   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In: 7.6.0

Description Simon 2010-05-25 11:45:22 UTC 
Version:           1.3.0 (using KDE 4.2.0) 
OS:                Linux

There is a little problem with the curves dialog. When I move a node around and keep the mouse button pressed, digikam starts calculating the changes as soon as the pointer rests for some time. When I release the mouse button while digikam is calculating the effect, the node will stick to the mouse even though the mouse button isn't pressed anymore.

Reproducible: Always

Steps to Reproduce:
* Open a big picture (so calculating the effect takes a little longer :))
* Open the Curves dialog in the Editor
* Drag a curve node around, and, as soon as digikam starts calculating, release it



OS: Linux (x86_64) release 2.6.33-4.slh.1-sidux-amd64
Compiler: cc
Comment 1 Marcel Wiesweg 2010-06-04 22:44:05 UTC 
Yes I can reproduce that.
The curves widget is disabled as soon as the filter is started. When disabled, it will simply not receive mouse events.

How to fix that?
1) Drop the dragged point when the widget is disabled. Problem: The point will inadvertently be dropped when just remaining in place for some time. Not acceptable.
2) Do not disable the widget when the preview is calculated. But is the filter prepared to get signales while calculating? Could introduce new subtle bugs.
Comment 2 Simon 2010-06-13 18:07:52 UTC 
I agree.

And, isn't it a speed issue as well? On my machine (Core2Duo 3.16 GHz) I have to wait for a full second until I get the adjusted image. Something more dynamic, real-time like would be cool. How about
* Scaling down the image to get the result faster? Or, even better,
* Using the GPU (if available) for these calculations?
Comment 3 Marcel Wiesweg 2010-06-14 18:39:16 UTC 
I can now attempt a fix like 2) above, with 1.3.0 out the doors.

In your second, do you count the time for moving the point, or from the time that the cursor becomes the waiting cursor? That is because, there is an initial delay before recalculation is done.
Comment 4 Marcel Wiesweg 2011-01-27 19:54:01 UTC 
It seems I cannot reproduce anymore with 2.0. But this dependence on mouse acrobatics, so could someone please try as well?
Comment 5 Simon 2011-03-17 15:23:45 UTC 
Cannot reproduce anymore. Thanks!