Only clear to background color if index is non-zero.
Fixed a the disposal test gif I was using - now renders properly (gif has no transparent set, but all renderers still considered it transparent. Spec says 0 should be ignored if 0, but was confusing by saying it only in the context of the pal not existing.. but seems to be the case always.
- Fix an issue where the spec of the gif for restore to previous uses code 3, not 4.
- To get results that worked - made an assumption that "clear to background" meant "revert back to what was there before I drew", where mode 1 would revert back to the previous frame [slightly different]. If I clear to background color instead, I ended up with large opaque squares in gifs that changes their transparent colour each frame.
- Background color is supposed to be used only for pixels not rendered by the image, so took that to mean it only really affected the previous frame, or potentially any frame that used full disposal. Since background color is allowed to be unspecified this is what lead me to believe I shouldn't use it for disposal.
- Oh, also upped the codes table to 8192 as 4096 ended up being too small for a few of my test cases.
Full disclaimer - I only read through the GIF format for this contribution, so competly could be misinterpreting the spec - but this gave me reuslts that matched Chrome.
- 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.
This is 3 short fixes for the file test_truetype.c.
1. Fix the Visual Studio Secure CRT Errors by defining
_CRT_SECURE_NO_WARNINGS
2. Fix signed/unsigned Character conversion warning/error.
3. Fix the Definitions for the Image packer.
This now works as intended generating usable png files.
My clang doesn't like the macro defined this way, choking at the callsite on line 195 with "too many arguments provided to function-like macro invocation"
This change matches what is done for STBTT_memset in stb_truetype.h
Someone should double check that that I didn't change
the behavior of any of the code. I'm not using most (if any)
of the code I touched, just wanted it to compile...
* `force_filter` being < 0 means the original behavior (i.e. figure out
the best-performing filter per scanline); any other values 0 <= x <= 4 correspond
to PNG filters (0 = none, 1 = sub, 2 = up, 3 = average, 4 = Paeth).
* `compression_level` being < 0 equals `compression_level` 8 (the previous value).
The higher this is, the better the compression should be (though it will use
more memory).
These new parameters are not (yet) exposed for the higher-level API functions.
...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.)
