| Age | Commit message (Collapse) | Author |
|---|
|
I'm probably going to borrow some of these for headless text
rendering in vwm/vmon, just doing some paperwork first.
|
|
Instead of rigid txt_align_t enums to specify how the text is
aligned relative to the x/y coordinates, you specify float
offsets in normalized coordinates -1..+1 allowing fine-grained
control of the offsets.
modules/asc will use this to automatically adjust the offsets
when requested, so x/y coordinates may be varied dynamically
using taps with the text automagically adjusting its offset to
try stay in-fragment.
|
|
Mechanical rename to txt_render_fragment_aligned(), updating all
existing call sites accordingly.
This is a preparatory commit for introducing an offsetted variant
of txt_render_fragment() (txt_render_fragment_offsetted()).
No functional difference, purely naming changes.
|
|
Silly oversight preventing some haligns from working right if the
string doesn't have a newline... uncovered while testing a new
txt module's alignment settings.
|
|
I thought the build was already using -Wall but that seems to not
be the case, maybe got lost somewhere along the line or messed up
in configure.ac
After forcing a build with -Wall -Werror, these showed up.
Fixed up in the obvious way, nothing too scary.
|
|
|
|
Just adds TIL_FB_DRAW_FLAG_TEXTURABLE so callers can granularly
inhibit texturing if desired.
|
|
Largely mechanical rename of librototiller -> libtil, but
introducing a til_ prefix to all librototiller (now libtil)
functions and types where a rototiller prefix was absent.
This is just a step towards a more libized librototiller, and til
is just a nicer to type/read prefix than rototiller_.
|
|
This is as basic as it gets, the only fanciness is it recognizes
newlines and supports horizontal and vertical justification.
As this is intended to be run from potentially threaded fragmenter
renderers, it receives a fragment and *frame* coordinates for the
text to be rendered. If the text doesn't land in the given fragment,
nothing gets drawn.
Currently this is not optimized at all. There's a stubbed out rect
overlap test function which could be used to avoid entering the
text rendering loop for fragments with zero overlap, that's an obvious
low-hanging fruit optimization. After that, skipping characters
that don't overlap would be another obvious thing.
As-is the text render loop is always entered and the bounds-checked
put pixel helper is used. So every fragment will incur the cost of
rendering the full string, even when it's not visible.
For the rtv captions this isn't a particularly huge deal, but stuff
to improve upon in the future.
|
