Re: [gtk-list] Re: Drag and Drop, try 1

[Elliot Lee <sopwith redhat com>]

On Fri, 13 Jun 1997, Otto Hammersmith wrote:

> Let's just hope they're bright enough to use OffiX. :)

Heaven help them if they do. OffiX has a lot of shortcomings, and the
'phase 2' talked about on the OffiX home page is nowhere in sight.

I think we need to lay out what we want in a DnD protocol and make it
happen. The KDE people and Troll Tech people probably have some thoughts
on this too.

> I don't think fragmentation is going to be a problem for most
> applications... if bunches of widgets are being allocated and
> decallocated, the allocator probably will find a perfect fit chunk
> from the last time it (or another of it's type) was allocated.
> Something like gzilla might start having problem, since it will be
> constantly allocating new and different widgets, but web browsers are
> notorious for being HUGE... I'd bet that gzilla ends up being one of
> the smaller ones.
> 
> I will admit the overhead of wasted space in small allocations is
> something to think about... I believe S&P already are.

A good approach to take is the pool allocator. apache does this to avoid
memory leaks. Basically you allocate a "pool" of memory that is
approximately the size that you expect to use for a particular object.
Then from that pool you allocate subpools and/or blocks and use them for
The neat thing is, you can free a pool and all the blocks/subpools within
it are freed as well.

So for example the gtk_init could malloc() all available address space
(Linux won't actually give it the memory until it is used), and then as
needed new windows could grab subpools/blocks of this memory and allocate
them for widgets...

alloc.c in apache is the place to look, it has a complete implementation
of this that we could "steal" :-)

-- Elliot		http://www.redhat.com/
How do you explain school to a higher intelligence? 
                -- Elliot, "E.T."