Re: Reported memory leak

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> 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?

>  - 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?


> 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..


 
> 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?

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

Okay, I figured since it queue all of them it would perform all
of them.  If it is throwing most of them out that would stop a
lot of flicker.  (However, I still wonder why queue them in
the first place if they are just going to get tossed.)

> All fixed in GTK+-1.4.

Will pass that on.

--Karl