Introduce a rewritten picojpeg that is able to operate statefully and
rasterize into an internal line ringbuffer, emitting a line of pixels
at a time to the caller. This is the JPEG equivalent of the lws
PNG decoder.
JPEG is based around 8- or 16- line height MCU blocks, depending on
the chroma coding, mandating a corresponding internal line buffer
requirement.
Example total heap requirement for various kinds of 600px width jpeg
decoding:
Grayscale: 6.5KB
RGB 4:4:4: 16.4KB
RGB 4:2:2v: 16.4KB
RGB 4:4:2h: 31KB
RGB 4:4:0: 31KB
No other allocations occur during decode.
Stateful stream parsing means decode can be paused for lack of input
at any time and resumed seamlessly when more input becomes available.
The adapted upng has a very compact fully-stateful lws-aligned
implementation already.
Adapt it to also be buildable and operable standalone, and to
understand gzip headers.
Provide some apis to inflate gzip simply reusing opaque inflator
contexts from upng.
Provide an api test that inflates gzip files from stdin -> stdout
Add a rewritten version of upng that decodes statefully line by line, and so
does not require a bitmap buffer for the output. This compares to original
upng approach that needs heap allocations for the input, the whole output
and intermediate allocations.
Instead of buffers for input, decompression and output, it only allocates
2 x lines of RGBA pixels (ie, a few KB), and 32KB of decompressed data for
backward references in the decoder, and decodes as needed into the 2-line
buffer to produce line rasterized results. For a 600px width PNG, this is
just 40KB heap for the duration.
This introduces a fixed precision signed 32.32 fractional type that can
work on devices without an FPU.
The integer part works as an int32_t, the fractional part represents the
fractional proportion expressed as part of 100M, so 8 fractional decimal
digit precision which is more than enough for many applications.
Add and Sub are reasonably fast as they are scaled on to a combined
uint64_t, Multiply is a little slower as it takes four uint64_t multiplies
that are summed, and divide is expensive but accurate, done bitwise taking
up to 32 iterations involving uint64_t div and mod.
mbedtls seemed to realize that they went overboard with the privacy stuff
on v3.0 and removed some of it. Introduce support for those members that
are only private on exactly v3.0 and unprotected before and after.
This adds apis that enable usage of compressed backtraces in heap
instrumentation.
A decompressor tool is also provided that emits a textual
call stack suitable for use with addr2line.
Modern toolchains are fine with giving a typedef as a forward reference,
but gcc 4.3 can't cope with that and then seeing the real definition in the
.c later.
Just conceal the typedef and use the struct form for the forward reference
resolution type in the public header so even senior toolchains are happy.
This gives you a way to access VFS files via a generic SS.
Typcially you would use the default streamtype having set the ${endpoint}
metadata to file://mypath/vpath.suffix or similar.
The lws VFS lets you register handlers for path prefixes (like /myvfsname)
or suffixes (like .zip). Matches create a vfs fd that is bound to the
matching file_ops that receives the open, close, read, write etc
"syscalls" for lws VFS operations on the vfs fd.
This gives you a way not just to access files from the platform root
filesystem, but also VFS layers like DLO filesystem blobs, by name,
from a normal SS.
VFS needs some small updates... pass in the bound fops as well as the
context fops to the member callbacks. ZIP_FOPS only cared about doing
operations on the platform / context vfs to walk the ZIP file, but other
uses are valid where we are doing operation inside the bound VFS itself.
Also, stash a cx pointer into file ops struct for convenience.
Sequencer went away a while ago, remove api tests and minimal examples.
Use Secure Streams to get an object with a lifetime longer than a wsi that
can autonomously retry.
We don't normally see events on the wsi in this state, but it is possible
since warmcat.com lwsws asserted on it in WAITING_CONNECT.
Explicitly handle it so we don't blow up.
Ensure we still work with mbedtls_ssl_conf_verify() as well as
mbedtls_ssl_set_verify() if that's what we have got.
Make sure mbedtls tls validation is noisy and fast.
Disable Xenial + mbedtls in sai, it fails but not when the same
tests are run from the commandline. Very few people will be
using Xenial (2016 Ubuntu release) with mbedtls.
Add a generic struct to manage a buflist with an incrementally-consumable
head, and helpers to deal with retiring the last segment and starting the
new head.
The lws_flow is added to using the buflist member directly, it autohandles
SS window management to try to keep the total buffered at the client to the
window member limit.
This switches the current hello_world to be hello_world-policy now,
and hello_world is simplified to use the __default policy without any
explicit policy of its own.
Using the default policy means it relies on the system tls library to
validate the tls connections using system trust arrangements, that won't
work in cases where the configured tls library does not have its own trust
store.
Just like there is a default protocol provided if none is specified that is
suitable for handling http GET, introduce a default SS policy that is also
suitable for the case of http GET where the user trusts the CA using the
ssl library or system trust store.
