Re: Re: Help with flickering widgets when showing and hiding!!

[<crypto_stonelock sympatico ca>]

> From: Tristan Van Berkom <vantr touchtunes com>
> Date: 2004/07/22 Thu AM 11:24:41 EST
> To: crypto_stonelock sympatico ca
> CC: Maciej Katafiasz <mnews22 wp pl>,  gtk-app-devel-list gnome org
> Subject: Re: Help with flickering widgets when showing and hiding!!
>
> crypto > Alright i'll restate my problem without talking about the GtkList.
>
> I know, it must have been said before but, just because a GtkList *is* a
> GtkWidget (in OO terms), it doesn't mean that it behaves the same way as
> any other widget, I glanced at the source and the GtkList is quite a beast.
>
> for instance, look what it implements on its own:
>
>    gobject_class->dispose = gtk_list_dispose;
>    object_class->set_arg = gtk_list_set_arg;
>    object_class->get_arg = gtk_list_get_arg;
>    widget_class->unmap = gtk_list_unmap;
>    widget_class->style_set = gtk_list_style_set;
>    widget_class->realize = gtk_list_realize;
>    widget_class->button_press_event = gtk_list_button_press;
>    widget_class->button_release_event = gtk_list_button_release;
>    widget_class->motion_notify_event = gtk_list_motion_notify;
>    widget_class->size_request = gtk_list_size_request;
>    widget_class->size_allocate = gtk_list_size_allocate;
>    widget_class->drag_begin = gtk_list_drag_begin;
>    widget_class->focus = gtk_list_focus;
>    container_class->add = gtk_list_add;
>    container_class->remove = gtk_list_remove;
>    container_class->forall = gtk_list_forall;
>    container_class->child_type = gtk_list_child_type;
>    container_class->set_focus_child = gtk_list_set_focus_child;
>    class->selection_changed = NULL;
>    class->select_child = gtk_real_list_select_child;
>    class->unselect_child = gtk_real_list_unselect_child;
>
> This is an old old container implementation that should be avoided
> at all costs.
>
> So I'll assume that you have tested your scenario and that you have
> the same problem with, say a GtkWindow with some GtkButtons inside.

Then again, I would agree if I was using it as is; but i'm not as it didn't exactly do what i wanted nor how 
i wanted. I'm patching up what it lacks manually and for scrolling, i'm using gtk_widget_hide/ 
gtk_widget_show where it applies to "simulate" scrolling. My problem isn't a GtkList problem, its the same 
redraw problem everybody gets from not using a backbuffer before redrawing. Its the same problem game 
programmers are confronted with every day since the dawn of man :).
 
> crypto > I'm having problems with flickering when using
> crypto > gtk_widget_show/gtk_widget_hide. Is there any way to avoid flickering
> crypto > by maybe having the whole screen redrawn at once or something similar?
>
> I get a similar problem when displaying a GtkWindow with 12 album jackets,

There ya go :).

> I would like the entire screen to show up at once "blam" prerendered, I guess a
> little tweaking (maybe a custom implementation of the GtkWindow with an extra
> back buffer and a custom expose handler, I dunno) would do the trick, but so
> far I havent had any luck (there is a slightly perceptable "filling" of the
> screen widget by widget).

I came across this, but i can't seem to find gtk_window_start_pain() and gtk_window_end_pain(). This seems to 
be part of the solution...if i can find those darn functions.

Here goes:

Backing Store 
To remove flickering, you want to have the ability to use backing store when drawing. The basic idea is that 
you call gtk_window_begin_paint() draw, then call gtk_window_end_paint(). There are some less-than-trivial 
issues here with figuring out what is the background of the backing stored region. When the 
begin_paint()/end_paint() is triggered from a expose-event, the interpretation is simple, since you have an 
area for the begin_paint()/end_paint() sequence. You initialize that area in the backing pixmap to the 
background color or pixmap for the window, paint, then copy only the area onto the window at v the time of 
end_paint(). 

However, the if you allow direct calls to begin_paint()/end_paint(), things become more complicated, since 
there is no area involved. The simplest way to handle things is to force the caller to pass the area into 
begin_paint() and to paint this entire area from the backing color/pixmap up. If you don't pass the area in, 
then you need to keep track of the extents of each drawing operation; if you don't force the caller to draw 
from the ground up, then you need to copy the current contents of the window onto the backing store and 
handle any GraphicsExpose events that this causes.

> So, Can you have your entire screen redrawn at once ? Not for free,
> you'll have to write that up yourself (and if your feeling generous,
> you could post that source ;-) )
>
> As far as child widgets (or list items) in a gtk list go, if they are
> less performant than child widgets of a non-depricated GtkContainer,
> you can definitly blame that on the GtkList.
>
> Cheers,
>                                    -Tristan

Yall stop yall bashing my GtkList ;). I'm pretty much just using it as a container anyways. Not using its 
functionnalities. I could have used a chained list constructed from a struct would have been pretty much the 
same but i needed a widget equivalent of that so I could have them show on screen without having to design a 
whole widget on my own so GtkList here you go :).

aXoneX