Re: libmng data-push mechanism(s)

On Thu, Apr 08, 2004 at 09:57:27PM +0200, Gerard Juyn wrote:

> The first question is: how volatile is that buffer? If it remains available for the 
> lifetime of the animation great. But I doubt if that's the case.

Yes, obviously libmng needs access to the buffer while it's 
relevent to decode.

> So the second question is: can onwership of this buffer be relinquished?
> Eg. can libmng take ownership of the buffer and perform the free() call?
> If so it could save a buffer-copy operation (which Ralph seemed anxious 
> about, and for good reasons of course).

As long as the it does the free() through a client callback, this is 
fine. Then the client can actually call free() release a reference, or 
whatever.

I'd like to see something like:

  mng_readbuffer_in(mnghandle, buffer, size);

After calling this, the client guarantees the referenced segment of 
memory will remain available until libmng calls:

  mng_readbuffer_release(userdata, buffer);

which is a client callback. If you want to be more general, you could 
include a size in the release call as well, but then it no longer maps 
cleanly onto malloc() and free().

> But I *will* have to buffer the data inside libmng until it (libmng) is ready to read 
> some more. Changing the whole reader-mechanism is pretty much beyond the 
> scope of the current excercise.

Well, if you put in a good API you can always optimize later...

> Of course I can also offer both methods (for reasons of flexibility) where in 
> the one case ownership is transferred and in the other the buffer gets copied 
> to a new one. That way you (and the next guy on the block) could decide 
> which method would suite your needs best.

I don't know that it's so important; either way you have the memory 
footprint. A submit/release scheme covers our requirements, and I don't 
think it's much extra work for someone who just wants to push and 
forget.

Of course, if you *really* care about memory footprint, you need to be 
able to seek to recover past chunks you need that you don't have room to 
store. :)

> All in all I think it shouldn't be more than a couple of hours of work. The key 
> issue will be when these hours will be floating past with nothing more 
> pressing to fill them with...

Thanks for being so responsive though; it's really helping our project.

 -r

--
Send the message body "help" to [email protected]