Re: Reported memory leak

[Owen Taylor <otaylor redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:

> > 
> > A few comments:
> > 
> >  - See bug #1874 
> >  - The right thing to do here is store invalid regions. Already
> >    done for GTK+-1.4
> 
> I think this was actual queue resizes and not queued redraws,
> therefore regions don't even need to be considered.  Are 
> the resize requests automatically squashed in gtk+ 1.4?

Resize requests are automatically squashed in GTK+-1.2.

In gtk_container_queue_resize():

  if (GTK_OBJECT_DESTROYED (container) ||
      GTK_WIDGET_RESIZE_NEEDED (container))
    return;

  [...]
  
	      GTK_PRIVATE_SET_FLAG (container, GTK_RESIZE_NEEDED);
	      resize_container->resize_widgets =
		g_slist_prepend (resize_container->resize_widgets, container);

> >  - Memory use growing without bound would probably still be
> >    seen here from the X event queue. 
> 
> Likely it could.  However, X is used for all applications so
> memory there can be pushed around a lot better than the queues
> in the applications.  Does Gtk+ store up the X queue locally?

It depends on exactly what is going on. If there are any roundtrips
between Xlib and the X server, than the events will get moved
into the local event queue. GTK+ tries very hard to avoid round
trips, so its possible that the riound trip.

> > I don't think increasing the complexity of the queue allocation
> > code would be worthwhile.
> 
> If the squashing of redundent events is in place the queue allocation
> likely isn't needed.  However, I have tested it with C++ and the
> ammount of code to handle it is pretty minumal if you don't allocate
> in pages.  Chunk allocation is considerably worse and slower if
> you want to deallocate..
 
True. GMemChunk is meant to do this, and its alloc-and-free-mode is 
rather slow,  hence we tend to avoid it. GMemChunk, in general,
doesn't make a lot of sense when you have a fast, efficient,
allocator like the one in GNU libc.

I just don't think it is necesary to have queues that can grow
big enough that this matters.

> > No, the queue elements are currenty combined before processing the
> > redraw.
> 
> Why combine them on the redraw rather then on the insert?  Or
> will both be done?

Simplicity. On the redraw, combining is not done just within one
window, but between multiple windows. Doing this on insert would
be very hard, so you'd need to have two combining passes one
on insert, one on redraw.

But the code is already, without this, vastly to complex. The right
thing to do is per-window-invalid regions, as done in GTK+-1.4, which
is much simpler, and more efficient.

Regards,
                                        Owen