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.
at the moment, default text will always come back if you
remove the text so there is no text in the field (for example,
you start typing, and then you decide you want to start over,
the suggested text re-appears).
this change makes it so that once you start typing, the suggested
text does not return. Furthermore, it counts the initial backspace
as a key that's hit, so you can clear the suggested text by just
hitting backspace.
So there's a bit of a nasty bug that arises from the GAM
both handling drawing primitives and context swaps.
In particular, because the GAM handles both of these in a
single thread, context swaps can't block, because the redraws
triggered by the context swap would be blocked, causing a deadlock.
When the API token for the predictor was introduced, this added
a blocking operation inside the context swap. This would cause
a deadlock under certain conditions.
This patch refactors the API token so that it's not a return
result of swapping the predictors. Instead, the predictors
return the API token as a non-blocking message to the GAM. This
API token is correlated with the *GAM* token (not the app token).
Present me thanks past me for adding the GAM token, which was
as of yet unused, but now, there is a very sensible role for it--
exactly what it was made for, e.g. handling GAM-local API calls
without disclosing the application token.
Anyways, hopefully this patch puts the race condition to
rest, while allowing us to have per-context prediction histories.
The prediction API now takes an API token. This is a 128-bit
number that gets passed to the prediction engine, and it's meant
to be unique for every context that requires a predictor.
It's up to the prediction engine to do anything with the token.
For the "null" engines (such as the icontray for `vault` and
`tts`) the token is just ignored. But for example, in `shellchat`,
the API token is used to store a history record in a HashMap on
a per-token basis. This means that every app that uses the
`shellchat` history function gets their own history that can only
be read out by that app.
The actual token itself is mostly passed through the API. The
token storage is in the Context layer (each Context has a record
for a token, that starts as `None`), and is passed down to
the predictor every time the context swaps, and the predictor
receives the token and passes it back if the token was `Some`,
or allocates a new random token if it was `None`.
Note that everything is a Context, including, for example, menus and
modal dialog boxes, but not all contexts have predictors. Only
Contexts that ask for a predictor have them. This mechanism
works smoothly in this model (as opposed to other hacks and work-arounds
previously tried getting to this solution).
in "menu mode" the predictive area functions as four menu
option keys instead of dynamic prediction updates.
this patch is mostly working but we need to figure out how to
force a redraw of the predction area when the app is raised,
because we get a stale image from the previous app on context
switch.
This allows for `ditherpunk` config to have a much larger
stack size on select processes only.
The cost comes at a 4k fixed overhead for the sacrificial
wrapper thread, so we lose about 20k of runtime RAM, even
when ditherpunk is *not* activated (because we're
always wrapping the threads).
There is no impact on scheduling or CPU utilization, as the
wrapper thread blocks and is never scheduled once the real
main starts. However, it does subtract one thread from the
total available thread pool.
for some reason I was setting the state of a canvas to not drawable
when the clip rectangle was being reset, causing dynamic dialog boxes
to become static if the content inside changes size.
I think this is an artifact of a previous generation of this code,
so commenting that out, but left a breadcrumb is case I'm wrong.
