Hi,
I am not sure if I understand your scenario correctly.
Why don't you put the icons out of the viewport, aka:
VBOX
+ up indicator icon
+ Viewport
+ down indicator icon
in your key-press handler, you scroll the viewport, and show/hide the
icon.
Because the visibility of the icon rarely changes, the allocation of the
Viewport is not changed very often. Neither will the allocation of the
widgets inside the viewport change.
The problem of your implementation, (perhaps) is that you add/remove
those indicator icons in every keypress event. The add/remove causes a
resize to be queued, thereafter every widget is redrawn, and flicker
occurs.
Regards,
Yu
On Fri, 2009-01-02 at 03:13 +0200, Bert wrote:
> 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
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
