i've already explained all this already, and you should be experimenting more if you want to deepen your understanding of this. events go to widgets not windows (even windows-only events like configure are still delivered to a GtkWidget, not a GdkWindow). if A is the parent of B, then a redraw of B will show up as an expose/draw request on A, at least under many common circumstances. you can't prevent this, but as i have explained, A will be told the *AREA* that is to be redrawn (or, in gtk3, will be given a cairo_t that is clipped to the area already), and as a container widget one of its jobs is to figure out which child widgets will be redrawn.
the full story is more complex than this, but if you want to know it all, you will need to experiment and read code. On Mon, Jul 29, 2013 at 4:37 PM, Виталий Кирсанов <krokozia...@gmail.com>wrote: > Thank you, Paul, for aswering to me, I wouldn't like to bother you much. > But maybe I didn't explain my configuration clearly enough. But since my > children widgets have their own GDK windows then expose events must be sent > directly to them (because a window's events are sent to the widget pointer > to which is stored as the window's user data), mustn't they? That is if the > parent container A has its own A_GDK_WINDOW window and its child B has its > own B_GDK_WINDOW window then the events from A_GDK_WINDOW will be sent to A > widget and the events from B_GDK_WINDOW will be sent to B widget, directly, > will not they? > > If yes then why if I call gtk_widget_queue_draw(B) then A widget receives > expose event as well as B? Or Does gtk_widget_queue_draw() applied to any > widget causes redrawing of the whole widget hierarchy up to the root window > widget? Can it be prevented in any way? > > BR, Vitaly Kirsanov > skype: vkirsan > > > 2013/7/29 Paul Davis <p...@linuxaudiosystems.com> > >> expose events are sent to widgets, not windows. it is up to the parent to >> decide how to forward an expose event to its children (including whether or >> not to do so at all) >> >> >> On Mon, Jul 29, 2013 at 3:17 PM, Виталий Кирсанов >> <krokozia...@gmail.com>wrote: >> >>> But, my child widgets have their own GDK windows. Do they have anything >>> to do with the parent GDK window when it's time to redraw a child? >>> >>> BR, Vitaly Kirsanov >>> skype: vkirsan >>> >>> >>> 2013/7/29 Paul Davis <p...@linuxaudiosystems.com> >>> >>>> redraws (expose events) always contain an "area" to be redrawn. the >>>> parent widget should ideally only redraw the specifiied area, especially if >>>> a full redraw is expensive. your parent needs to determine which children >>>> and which (if any) background needs to be redrawn. >>>> >>>> >>>> On Mon, Jul 29, 2013 at 4:52 AM, Виталий Кирсанов < >>>> krokozia...@gmail.com> wrote: >>>> >>>>> Hello list. >>>>> >>>>> I have two custom widgets: widget A is a container, widget B is a >>>>> simple widget. Both of them are window widgets. Widget A can contain a lot >>>>> of instances of widget B. >>>>> >>>>> The problem is when I call gtk_widget_queue_draw() for an instance of >>>>> widget B it also causes the parent widget A to get redrawn as well. >>>>> Considering that the drawing widget A depends on all of it children (i.e. >>>>> their positions and sizes) it can lead to quite an overhead which is not >>>>> needed in this case (that is if the instance of B being redrawn doesn't >>>>> change its geometry). >>>>> >>>>> So, is there a way to prevent the parent window widget A from >>>>> redrawing in case of one of its window children B gets redrawn? >>>>> >>>>> BR, Vitaly Kirsanov >>>>> skype: vkirsan >>>>> >>>>> >>>>> _______________________________________________ >>>>> gtk-list mailing list >>>>> gtk-list@gnome.org >>>>> https://mail.gnome.org/mailman/listinfo/gtk-list >>>>> >>>>> >>>> >>> >> >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
