Decode to existing buffer about lodepng HOT 4 OPEN

Much needed feature request from 2015.

from lodepng.

Hi,

This, along with better custom malloc support, is a big internal and API change, but planned at some point. Tho not soon for now.

To understand why the API is as-is: it was designed mainly for easy, one-function-call usage to load textures in games, in environments where memory usage is of no concern.

from lodepng.

@lvandeve Hm, does this really require an interface change? Couldn't the existing function just call two support functions--one that gets the width and height, and another that does the decoding into a buffer big enough for that width and height? Then clients who want to do their own allocation just call those two support functions directly?

I note that getting the width and height is already supported as lodpng_inspect(), so really this just means one needs to name the version that decodes into an existing buffer. Nothing in the interface has to change.

from lodepng.

@lvandeve I agree to @hostilefork .

This problem can be solved simply by customizing the part of decodeGeneric() which forcibly substitutes the buffer of lodepng_malloc () for out.

You may provide additional arguments to change the mode of operation, or create a new function to write to the existing buffer (that is not difficult at all).

Simply, I think that it should be treated as an external buffer and skip allocation, if out has a value.

However, what I have to advise is that the current export buffer has a clearly incorrect padding method.
It seems that lodepng_get_raw_size () is used in calculating the buffer size.

This is the correct calculation method:

return ((w * bpp / 8 + 3) / 4 * 4) * h ;

Each row of pixels must fulfill a 4-byte alignment.

Likewise, you should also manage bytesPerLine so that other buffer formats are acceptable.

from lodepng.