GNOME Bugzilla – Bug 109179
Optimize out itsy-bitsy updates to a progressbar
Last modified: 2013-11-10 06:22:34 UTC
If I update the progress-bar in 0.01 percent increments, it will queue a redraw every single time. While doing incredibly small updates is silly, it's pretty easy to do and people shouldn't have to worry about it. I think it's worth adding the necessary optimizations so that change that doesn't move the progress bar and doesn't change any displayed overlay text doesn't cause a redraw.
Looks reasonable involved - involves: - Caching the old percentage, probably in instant private data. (Though we might be able to reuse pbar->activity_pos to be the 'amount' for continuous mode.) - Dealing with the different modes: - For continuous mode, queue a refresh if the 'amount' parameter changes. - For activity mode, queue a refresh if activity_pos/activity_step change (we are already computing the new values in gtk_progress_bar_real_update, so this - discrete mode is already handled - Dealing with the possiblity of format strings that change with the value. (Either compare new and old strings, or just turn off the optimization when there is a format string, since that is a deprecated feature.)
Actually, it cannot happen at all that real_update() doesn't change the value, unless pulse_fraction is too small in activity mode, in which case we don't update at all. There should probably be a MAX(1,...) somewhere in the code for setting the activity_step.
Hi!!! I've been reviewing this bug and I'm not sure about which would be the right behaviour of the progressbar, in order to propose a patch. I mean: when in activity_mode, what should happen when pulse_fraction is small enough not to move the block of the progressbar? There are two options: - Force a one-pixel-movement, not allowing activity_step to be less than 1, and redraw - Don't force movement, allowing activity_step to be less than 1, and not redrawing cause it's not necessary What do you think? Another question: when in continuous mode, I was thinking about using the flag dirty to avoid redrawing. As you said, I could store the old value and calculate if the redraw is needed in real_update but, couldn't I make that calculation in set_fraction and set dirty to TRUE? I know I would need to modify real_update to do this, but I think it would be a more elegant solution. As soon as I know about your opinion I will propose a patch to the bug :) Greetings!!!
Created attachment 92940 [details] [review] Patch to solve the unneeded updates Hi!!! This patch tries to solve the bug in the 3 possible modes: - Discrete mode: nothing to do. - Continuous mode: in gtk_progress_bar_set_fraction we calculate the size of te scrollbar to paint, both with the old and the new percentages. If the sizes are different, then a redraw is needed, and it's indicated setting thr flag dirty to TRUE. The real_update function has been modified so when in continuous mode it doesn't modify the flag dirty. - Activity mode: when calculating the activity step, we put a MAX (1,...) to avoid zero sized steps and unneeded redraws. This way a minimum of a one pixel movement is forced. I hope it helps :) Greetings!!
Created attachment 137751 [details] [review] gitified patch converting patch to actual version (leaving the changelog part away) untested…
Review of attachment 137751 [details] [review]: ProgressBar code looks to have been rewritten since this patch was created. Is this bug still valid?
lets close this for now