Re: [gtk-list] Re: [patch] gtkviewport optimizations

[Patrice Fortier <Patrice Fortier aquarel fr>]

> 
> 
> Patrice Fortier <Patrice.Fortier@aquarel.fr> writes:
> 
> > extract from gtk-fortier-980128-0.patch.README:
> > 
> > This patch is a an optimization (cleanup) of the gtkviewport widget.
> > 
> > The viewport widget has 3 windows:
> > the main window (wigdet->window), a clipping window and a window
> > which contains the child widget.
> > The only window which needs to get events (expose, clicks...) is
> > the main window. The 2 others almost never recieve any event, and
> > when they do, they don't do anything.
> > This patch explicitly tells the X server that these 2 windows 
> > don't care about events.
> 
> I'm not sure this is right (it might be right for the clipping
> window, but not for the child window). The child window needs
> to get expose events (see below) and should also get whatever
> was set with gtk_widget_set_events.

hmmm. 
I think you're right.
I assumed that a widget which was drawing somewhere (its shadow
for example) was drawing in one of its window.
I looked at the code of several widgets and I saw that it was
totally false.
A widget draws most of the time in one of its parent  window ...

I think this was a choice to optimize the number of windows 
created. In an other hand I'm pretty sure that it'll bring some problems
on us sooner or later.
If Raster is reading this, he must be jumping on his seat like a
kangooroo (don't know the spelling in australian :)).
I don't consider thatit's safe for a widget to draw in an other one.

Forget the second part of my patch.
In the current implementation I'm just plain wrong.

Question: 
Does anybody know about multiple-window overhead or about mapping/
unmapping windows when they're not on the screen?
If we can find a clean and *fast* solution to this... "problem" :)

Thanks for your time,

Patrice