This is just the TextView primitive with a "state" variable added
that controls how far the strips should march across the screen.
Users can specify with or without a bounding box.
The exact location of the text within the bar depends on the
BoundingBox option picked.
The primitive computes the total region to animate based upon
the typesetting engine's output. Thus it is not recommended
to "compress" the amount of whitespace allocated to the animation,
because it can cause the animation to have artifacts due to
whitespace overflow of typesetting.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
Fixes crashes on macOS.
Some operating systems and GUI frameworks, in particular Cocoa, don't
allow creating an event loop from a thread other than the main thread
(TID 1) and will abort a program on violation.
- remove a blanking operation. this makes the transision from
loader to runtime almost imperceptably smoother
- add the ability to summon the logo screen earlier in the process
Note that only GAM can call GFX, so, it's alright to expose that
API, since GAM should gate-keep and prevent abuse of that function.
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
When ditherpunk flag is enabled, graphics-server cannot start.
I suspect macOS doesn't tranfer thread-local variables when a new one
is spawned, and this makes xous-names, logs crash.
This commit adds a compile setting that will bypass ditherpunk thread
settings on macOS as well, allowing developers who happen to run this OS
to develop and prototype for betrusted again.
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
the loader is a little funky, and requires some maintainer hand-holding
due to the split of the page ownership between the root-keys
crate and the graphics-server crate.
Improved docs so I don't forget this detail in the future.
The `ManagedMem` thing for the suspend/resume crate is simply
a disaster. It tries to be fancy and Rusty and really it just fails
in non-obvious ways. This is one of the places where it simply
does not pay to make things seem so simple.
Why? because in reality, memory is complicated. It comes in pages.
There's initialization. There's caching. There's volatility.
I haven't encountered a single situation where the assumptions
of page-alignment and memory layout have really lined up well enough
for this primitive to make sense. The "idea" was hey, since
you allocate a peripheral MemoryRegion, why not just use its attributes
as a marker to a suspend/resume thing that automatically handled
stashing that MemoryRegion to a backing store inside RAM? Seems
simple right? wrong. Every time I've tried to use it, it's failed
in non-obvious ways.
In this most recent incarnation, it turns out that for whatever
reason, it seems to be just stashing about the first 4-8k of the
framebuffer to the SR backup region, and then somehow grabbing
a future(?) copy of the memory? or maybe just a wrong copy? I don't
know. The code seems simple enough but it goes through some
traits and some type transformations and then there's some unsafe
code to make it volatile and it doesn't work.
Instead, we just use a damn [u32; FB_SIZE] slice to store the
frame buffer. This is so obvious and easy. The only price is
you have an "ugly" `fb[..FB_SIZE].copy_from_slice(&self.srfb)`
line instead of an "elegant" `srfb.suspend()` invocation.
Stashing into it is a bit uglier, because we have to cast the
slice to an unsafe pointer in order to access the `write_volatile()`
method. But, it works! It. Just. Works. And you can see what's going
on. Really, I should stop trying to be fancy and just be readable.
OK anyways, that was that rant. This commit also adds some
calls that allow us to re-use the suspend/resume frame buffer during
"normal" times as a stash/pop for the application image. This is
nice because the memory is normally idle/overhead when not
in suspend, so now we're repurposing some already-allocated memory
to accelerate some drawing operations, and it also makes, crucially,
a multi-step blocking modal dialog interaction less cosmetically
jarring, because the application thread can be fully blocked and
not responding to redraw commands but the stash/pop mechanism
creates the illusion of "everything is moving along".
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.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
Add a "Later" stage, and have exactly one "Last" stage.
"Last" to suspend is the ticktimer -- this is crucial for
basically everything else to work. The other really
low level stuff that needs to work to the last minute is
now in the "Later" bin.
previously blitstr2 is using usize for x/y coords, which means that
for layout purposes points could not go to the top or left boundary
without causing arithmetic overflow. Of course, you want to render
everything on-screen, but, as we have multi-line text with overflow
possibility, it's reasonable to be able to use negative coordinates
to locate text boxes that flow into the visible region.
This of course means that occassionally you can come out with
things like "negative widths", but even then, there can be reasonable
uses for this as an intermediate in calculations that ultimately
arrive at a positive result.
Really clear up the roles and structures of word wrapping.
Significantly, we have now figured out that the word wrapper
should be the word wrapper, and that the text bounds should
be computed by a text bounds computation.
Conflating flexible text bounds with word wrapping makes
the math really hard.
So, the word wrapper always works with a bounding area starting
at 0,0, and will wrap until it hits a Point designated as its
absolute max bounds.
The returned typeset block is referenced to 0,0, and then it
is shifted to the correct location by the rendering function.
This externalizes the computation of the final location plus
the rendering bounds to the outer functions that need to care
about this, thus simplifying the word wrapper significantly.
this just grafts in the new crate, while leaving the old crate
unscathed. once this is somewhat functional we'll excise the old
crate and reformat the loader for the "hard binary" image of
the fonts.
the trailing update after every event seems redundant now that
the gam is cleaned up
also fix a bug that causes overflow text on tl fitted text
to overflow the drawing region
