On Tue, Aug 10, 2021 at 2:59 PM Yannis Guyon <ygu...@google.com
> Thank you for your question. The link you gave is managed internally, there is no public repository containing the sources. Feel free to suggest edits here for review.
Thanks for the quick response :)
> Endianness was not specified because the memory buffer is supposed to be accessed as a uint8_t pointer. Using a higher bit depth than bytes will indeed have platform-dependent effects.
> MODE_Argb will be "big endian", meaning the alpha will be stored in the most significant bits of a 32-bit integer, *only* when accessing the data as uint32_t* on a big-endian platform.
This is indeed correct. I was thinking it could add some clarity that
it behaves this way. Also for many users relying on libwebp and other
libraries with the classic independent behavior, it can create some
confusion especially as from their side, no int32_t interactions are
done. F.e. it bites me while I was updating libGd WebP support
(options and adding more formats), easy to figure out but it can be
less obvious for other users.
My thought was to add the explanation you wrote very well :) with a
piece of code:
config.output.colorspace = MODE_Argb;
config.output.colorspace = MODE_bgrA;
config.output.u.RGBA.rgba = argb;
config.output.u.RGBA.stride = gdSurfaceGetStride(surface);
config.output.u.RGBA.size = gdSurfaceGetStride(surface) * height;
@pierrejoye | http://www.libgd.org