After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 109179 - Optimize out itsy-bitsy updates to a progressbar
Optimize out itsy-bitsy updates to a progressbar
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other Linux
: Normal normal
: Small feature
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-03-25 20:24 UTC by Owen Taylor
Modified: 2013-11-10 06:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to solve the unneeded updates (3.13 KB, patch)
2007-08-02 18:50 UTC, Miguel Gomez
none Details | Review
gitified patch (2.60 KB, patch)
2009-07-02 22:30 UTC, Thomas Spura
rejected Details | Review

Description Owen Taylor 2003-03-25 20:24:33 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.
Comment 1 Owen Taylor 2003-08-18 16:36:35 UTC
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.)
Comment 2 Matthias Clasen 2005-08-20 07:00:05 UTC
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.
Comment 3 Miguel Gomez 2007-03-29 19:03:19 UTC
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!!!
Comment 4 Miguel Gomez 2007-08-02 18:50:21 UTC
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!!
Comment 5 Thomas Spura 2009-07-02 22:30:27 UTC
Created attachment 137751 [details] [review]
gitified patch

converting patch to actual version
(leaving the changelog part away)

untested…
Comment 6 Timothy Arceri 2013-10-06 22:45:46 UTC
Review of attachment 137751 [details] [review]:

ProgressBar code looks to have been rewritten since this patch was created. Is this bug still valid?
Comment 7 Timothy Arceri 2013-10-06 22:46:09 UTC
Review of attachment 137751 [details] [review]:

ProgressBar code looks to have been rewritten since this patch was created. Is this bug still valid?
Comment 8 Timothy Arceri 2013-10-06 22:46:39 UTC
Review of attachment 137751 [details] [review]:

ProgressBar code looks to have been rewritten since this patch was created. Is this bug still valid?
Comment 9 Matthias Clasen 2013-11-10 06:22:34 UTC
lets close this for now