This incomplete PNG decoder presents as an Iterator reading u8 bytes directly from a Reader.
Aproaching a png decoder as an Iterator requires significantly less Heap than
the traditional batch aproach.
On Precursor, this enables PNG bytes to be intercepted at the network interface
and processed into the much smaller gam::Bitmap format without ever having to
store the original PNG file.
I had thought there was an issue with heap size limit increases
and multithreading but I think actually the problem is the
PDDB runs pretty close to the stack size limit. This increases
the stack size limit for the PDDB on boot and also bumps up
the heap limit so caching can work more flawlessly.
the core now enumerates after a suspend/resume cycle, although
sometimes it takes two tries for the enumeration to go all the way
through. not sure why, yet.
In retrospect forcing apps to manage their suspend in resume
crosses too many abstraction barriers.
Instead, the app should specify the mode of the hardware, but
then the driver should be responsible for restoring that state
on resume, not the app.
Instead of writing `Some(Opcode::*)` repeatedly, change it to simply
match against `Opcode::*`. This is accomplished by defining a new opcode
`Invalid` that will be matched against as a default.
Signed-off-by: Sean Cross <sean@xobs.io>
The new ordering remains the same size, but is no longer
`#[repr(packed)]`. This allows it to be `#[repr(align(4096))]` which
means we can get away with using a stack page for this struct instead of
allocating a new object every time.
Signed-off-by: Sean Cross <sean@xobs.io>
takes about 1MiB of heap to decode the test PNG.
Putting the heap increase at boot seems to not
work, it causes other processes to not spawn. The condition
is not terribly reproducible, so it's probably a concurrency
issue of some type.
