On Thu, 2010-09-02 at 16:58 -0400, Ted Unangst wrote:
On Thu, Sep 2, 2010 at 4:47 PM, Peter Cawley<lua@corsix.org> wrote:
My proposal is that the current image-related code is taken, and then
the calls to malloc/free which deal with the large buffer are replaced
with calls to some generic allocator. Then the above Lua-based
allocator is used as the generic allocator...
Very interesting. Thanks, that's a consequence I hadn't thought of.
I have a similar problem - I am currently creating a binding for the
OpenCV library. This solution cannot be applied in my case, because I
cannot (and do not want to) modify the library. A common pattern in
OpenCV is this (this is how I imagine the binding):
while not finished do
local img = cv.RetrieveFrame(cam) -- retrieves image from cam
-- do some processing
end
A full color image takes about 230K, and imagine 15fps - that is a lot
of data. Yes, I could force the end user to call img:Release() after
processing, but I want to spare him this step.
Since I cannot force the library to use my custom allocator (and the
image is allocated inside the library), I have to use boxed userdata,
containing a pointer to the image - and Lua sees that as only 4/8 bytes,
which may cause memory problems after some time.
