Reported memory leak

[Karl Nelson <kenelson ece ucdavis edu>]

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.


Perhaps someone can give me some insight at to what gtk+ is
actually doing which results in the large queue the user reports.

Thanks.

--Karl