Re: Reported memory leak

[Owen Taylor <otaylor redhat com>]

A few comments:

 - See bug #1874 
 - The right thing to do here is store invalid regions. Already
   done for GTK+-1.4
 - Memory use growing without bound would probably still be
   seen here from the X event queue. 
   
I don't think increasing the complexity of the queue allocation
code would be worthwhile.

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

> A recent report of a memory leak showed up on the gtk-- list.
> I don't believe is a leak but simply a bad section of gtk+ 
> code.  
> 
> In the demo program inclosed there is a loop which asks gtk+
> to switch pages 100000 times in a row.  Each page switch causes 
> a queue draw and resize.  Thus the queue system continues to
> allocate massive ammounts of memory.
>
> [deallocation of queues]
> Obviously there is no leak here.  However, it is bad that 
> the memory doesn't get freed when the free list grows very large.
> I have done some experiments and found that whenever the free
> list grows over 64 deleting half the elements in a batch will
> only increase the malloc/free cost 5% over allocation only 
> once with chucks you can't free, and this was assuming large
> cuch free ratios  (randomly allocate 1..32, randomly deallocate 1..32)
> x10000000 times.  The ammount of time save allocating in big
> chunks that can never be freed doesn't seem worth having all
> stages suck up memory.  
> 
> It seems to me that it would be best allocate a relatively average
> number of elements at the start of the code and then let that
> list grow until the free list grows to some reasonable size.  Beyond
> that point just dallocating half whenever the free list grows large
> would prevent large ammounts of memory from getting "stuck" in 
> a unit like this.
> 
> [smart queue]
> Beyond that I think there is a more fundimental underlying problem
> here if what I believe is happening actually is.  There is no
> reason a widget should have more the 1 item in the queued list
> at any point in time.  Anytime an additional queued request for
> that same item comes in with matching parameters the old request
> should just be moved to the end of the list.  This would save
> flicker as well as speed because it would prevent an item from
> answering a request over and over causing additionaly redraws.
> 
> This saves memory because in the list in this users case would
> never have grown.  It would have squashed all but the last sends
> forward and thus the window would have only be redrawn twice.
> (once for the window page which was immediately covered.
> 
> If this isn't being done currently, it could explain some of
> the flicker in gtk+ if an item is drawn twice because two
> items queue a redraw.

No, the queue elements are currenty combined before processing the
redraw.

The flicker currently is a) inevitable from clear-redraw without
double-buffering. b) made worse by a bit gravity of ForgetGravity.

All fixed in GTK+-1.4.
                                        Owen