Re: flicker with viewport and hbox

[Bert <bert ioniq co za>]

Hi,

Apologies for awakening my own thread again, but since it had been  
sent in the holiday season I was worried that insufficient gtk+  
experienced eyes may have seen it. Anybody have any ideas? Note that  
the issue can very easily be seen on a PC too if running the program  
in valgrind (which slows it down sufficiently for the problem to  
become evident).

On Thu, 18 Dec 2008 18:11:33 +0200, Bert wrote:

Hi,

I'm experiencing flicker for the following scenario (and I am a gtk+  
newbie): I have a viewport, containing a vbox container. The vbox  
contains a number of hbox containers, each of which essentially  
consists of label +icon+label (packed left, with shrink). Based on  
keypress/release events, the viewport is scrolled up and down (via the  
vertical adjustment component), and this same event callback modifies  
the top and bottom visible hboxes to add/remove an icon at the end  
showing up/ down arrows (as necessary) to indicate more items are (or  
are not) available (and the recently off screen hboxes have their  
icons removed). This unfortunately seems to result in the scrolling  
occurring first, repainting the viewport, and then the hbox icons are  
added and removed, which results in significant flicker (especially on  
a slow ARM CPU).

I've tried various things from various search results (relating to  
flicker) in the mailing list archives and google etc., but so far  
nothing works. What is the succinct and correct way to prevent flicker  
in this scenario, and/or is there a better way to achieve what I need  
that will avoid flicker? For my scenario, essentially the entire  
viewport needs to be redrawn when scrolling, so it would be good if  
everything was only drawn once to an offscreen buffer, and the  
onscreen buffer replaced. I actually thought this was supposed to  
happen automatically with the double buffering, but alas not, I guess  
I just don't understand when the double buffering kicks in (I thought  
all my updates would result in a union of invalid rects, which should  
boil down to the entire viewport, and then those would be drawn to the  
double buffer). I've also tried things like begin_paint_region/  
end_paint, but no matter what I do, its almost as though the hbox  
changes are queued somehow and only applied after the viewport has  
updated onscreen, and then those get updated onscreen again (so all  
the items scroll up or down, and then the arrow icons are added and  
removed). Hopefully I'm explaining this well enough...

(I'm actually using gtkmm, but apparently this is the correct mailing  
list to ask this question on, supposedly the gtkmm list is purely for  
c ++ wrapper issues)

Here is the relevant sample code snippet which occurs in keypress  
event handler:
  //Gdk::Rectangle rect(0,0,width,height);
  //this->get_window()->begin_paint_rect(rect);
  double v=vadjust->get_value();
  // (some code here which results in vadjust->set_value() being  
called to appropriately scroll the viewport)
  // (some code here which goes through the list of hboxes, and  
removes or adds an arrow icon to the end as appropriate (remove from  
recently offscreen items, added to now onscreen items, except for  
topmost and bottommost items)
  vadjust->value_changed();
  //this->get_window()->end_paint();

Here is typical code for how the arrow icons are added and removed  
from the hbox subclass (here called MyHBox):
void MyHBox::set_right_icon(const std::string file)
{
  if (file==right_icon_file) {
    return;
  }
  if (right_icon) {
    box->remove(*right_icon);
    delete right_icon;
  }
  right_icon=new Gtk::Image(file);
  box->pack_end(*right_icon, Gtk::PACK_SHRINK,2);
  right_icon->show();
  right_icon_file=file;
}

void MyHBox::clear_right_icon()
{
  if (right_icon) {
    box->remove(*right_icon);
    delete right_icon;
    right_icon=0;
    right_icon_file.clear();
  }
}

(ignore the fact that the code above gets the icons from files, the  
same problem occurs even if I use stock icons or embed the images in  
the binary etc.)

Thanks,
Bert