libgimp: improve gimp_progress_update().
- Do not only check the step width, but also the time interval between 2 progress calls. No need to run a PDB call, then update the GUI every millisecond or so. This would just unecessarily slow down the plug-in for updates which the user won't ever see. From my tests, 20 updates per second is plenty enough to have the progression look fluid. No need for much more. - Do not warn anymore on stderr when we drop progress updates. Even if just on the unstable builds, such warning is wrong. First because it depends on files and machines. Typically a lot of processing could set their progress updates relatively to layers. Yet we currently consider that 1/256 steps are too small. So what if you have more than 256 layers? This would make the same code print a warning on big files, and none on small files. The second reason is that we should not encourage plug-in developers to have limited progression updates, but the opposite (progression info makes for good feedback), neither should we expect them to compute the step size or the time between updates. It's a much saner approach to have them only take care about computing relevant update steps while our API focuses on filtering these in order to avoid overloading the GUI. It makes for good progression feedback, sharp GUI while not taking all CPU time on it, all this while making it easy on plug-in developers.
Showing with 26 additions and 20 deletions