Bug 173790 - edit previews happen too soon in showphoto
Summary: edit previews happen too soon in showphoto
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Showfoto-Core (show other bugs)
Version: unspecified
Platform: Fedora RPMs Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-28 22:38 UTC by Ryan McCoskrie
Modified: 2022-01-20 11:36 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan McCoskrie 2008-10-28 22:38:51 UTC
Version:           0.93 (using KDE 4.0.5)
Installed from:    Fedora RPMs

There should be a slight delay before showphoto (digikam as well most likely) updates preview windows or have an actual 'update preview' button so that the program knows that the change is what the user really wants.

This issue comes up when users make slight adjustments on edit tools(i.e a slight adjustment of thresh hold on the unsharp mask
tool) in sequence or by accident.

Showphoto will for several seconds refuse any input and crunch out maths with the wrong variables. When this happens several times in a row it becomes very frustrating and counter productive.
Comment 1 caulier.gilles 2008-10-29 06:16:47 UTC
lease, can you describe better the problem, because i think that it have been fixed in 0.9.5 and 0.10.0, but i'm bot sure?

Gilles Caulier
Comment 2 caulier.gilles 2008-12-10 19:30:13 UTC
Ryan,

This file still valid using showfoto for KDE4 ?

Andi, Mik, 

Can you reproduce (and understand) this problem ?

Gilles Caulier
Comment 3 Andi Clemens 2008-12-10 19:40:44 UTC
He is talking about that some effects will render immediately when changing settings (for example the blur amount slider). Some imageplugins take quite a while, so this can be annoying.

Andi
Comment 4 caulier.gilles 2008-12-10 20:10:11 UTC
Ok, now i understand.

But for long preview rendering, there are progress bar displayed.

Also, i remember that you have fixed preview rendering event to always use "Try" button. Right ?

Gilles Caulier

Comment 5 Andi Clemens 2008-12-10 20:14:13 UTC
Not in all plugins... only those that consume a lot of rendering time. But at least every plugin should have a timer, right? So it might not fire directly... this should be true for every plugin nowadays.
Comment 6 caulier.gilles 2008-12-10 20:20:43 UTC
It's already the case. A timer is used (500ms) to post an event to refresh preview when a settings is changed somewhere, especially with slider...

Gilles Caulier
Comment 7 Mikolaj Machowski 2008-12-10 23:51:40 UTC
I understand: when you make some adjustments in plugin by slider or changing value by button or moving points in levels/curves digiKam tries to compute preview almost immediately after change. When you are not very precise with your movements it can take several tries to achieve good result. And after each hesitation digiKam starts crunching introducing unnecessary delays.

Is it really 500ms? I have impression this is faster. Also reporter has older version of digikam where this problem was much worse.

Ryan - could you test with latest digiKam 0.9.4 or even 0.10-beta7? With those releases I think your report could be marked as INVALID.
Comment 8 Ryan McCoskrie 2008-12-11 01:47:56 UTC
...I won't change it to INVALID because is a fixed problem even if the reporting
and fixing were unrelated events.