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.
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
Ryan, This file still valid using showfoto for KDE4 ? Andi, Mik, Can you reproduce (and understand) this problem ? Gilles Caulier
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
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
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.
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
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.
...I won't change it to INVALID because is a fixed problem even if the reporting and fixing were unrelated events.