[gtk-list] Re: gtk_container_check_resize performance

[Raph Levien <raph acm org>]

On Sun, 11 May 1997, Peter Mattis wrote:

> 
> Raph Levien writes:
> >BTW, can anyone explain to me the rationale for why a widget should or 
> >should not have its own window? It is obvious why a viewport should be a 
> >window (a cheap call to XMoveResizeWindow gets the window scrolled), but 
> >far less clear why a button needs to be a window. For the time being, I'm 
> >using ifdefs so I can configure the html container to have its own window 
> >or not. So far, I can't see any difference, but when I start heavily 
> >nesting them (because that's how tables are going to work), it will 
> >probably become more significant.
> 
> Events. Events are generated (by X) on windows, so any widget which
> wants to handle anything other than the basic exposure events needs to
> create a window. In the instance of a button widget, it needs to be
> able to get mouse press and release and enter/leave notify events. 

Aha! I was wondering why I couldn't find the code that dispatched the 
motion notify events of a container into enter/leave and motion notify 
events of its children.

Now that I know this, it is obvious that the html container has to be a 
window, to deal with link click events (at the very least).

Am I correct in assuming that, if you did add event dispatching code to 
containers, it might be possible to make many widgets no_window, and 
thereby gain some performance?

Raph

P.S. I've taken a tour through the size negotiation section of gtk
(gtk_container_check_resize, size_request, and size_allocate). I feel like
I _almost_ grok it - it's complicated! I will stop yammering about it for
now, accept the fact that the first release of gzilla will have
performance problems, then do a thorough review later, with the goal of
getting size negotiation and redraw calls down to an absolute minimum. 
One thing is starting to become clear: gzilla will be a serious stress
test of gtk+. 

P.P.S. I have found on my own the answers to two of the questions I 
posted earler. First, the gtk_window_set_policy call does what I want 
regarding making the html window fully resizable. Second, the best way 
for the html widget to find out the size of its containing scrolledwindow 
(which is needed to control the set width of wrapped text) is to connect 
a little function to the scrolledwindow's size_allocate signal. This 
function subtracts a nice safety margin from the scrolledwindow's size, 
then hands it to the html to force a rewrap, if necessary.

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null