- Allow loading a gif as multiple frames into a single buffer. Each frame is a full image seperated by a (w * h * comp) stride.
- Optionally, can pass in a pointer to a int, which will be filled with an array layers long contain ms for each frame.
- Fix gif's not loading the initial transparent background
- I believe also fix disposal rules for subsequent frames (though being somewhat inefficient with memory to do so)
- Add a flip_vertical that takes into account slices as well.
Compiled using VS2017, but nothing else as I'm not really setup for it. Apologies.
...as present in MS TrueType files. Since this table is optional,
the new stbtt_GetFontVMetricsOS2 has a return value and can fail.
This is a replacement for pull request #463.
Fixes#463.
This incorporates #462, but also factors everything into one
function that is shared between 8-bit integer, 16-bit integer, and
float pixels (vertical flip operates on rows of bytes and doesn't
really care), and finally always uses a 2k on-stack buffer without
dynamic memory allocation, doing multiple memcpys per row if
necessary. Not only does this remove an out-of-memory failure mode,
it is also preferable for large images, since it's more
L1-cache-firendly this way.
Fixes#462.
1. const char* for __FILE__ (string literals are const)
2. Use %zd to print size_t where available; the only real problem
here is Visual C++. Use long long on the VC++ vers that support
64-bit targets but not %zd, int on the even older 32-bit-only
VC++ vers that don't support "long long" either.
Fixes#459. I think. (It's hard to be sure since the issue doesn't
state the exact warning message.)
We used to require exact match between img_len and raw_len for
non-interlaced PNGs, but the PNG in issue #276 has extra bytes
(all zeros) at the end of the compressed DEFLATE stream.
The PNG spec doesn't have anything to say about it (that I
can tell), and if libpng accepts this, who are we to judge.
Fixes issue #276.
