til_fb: fix til_fb_fragment_fill() memset() misuse

This braino wasn't actually showing itself in any output since it
was always being used to fill either 0xffffffff or 0x00000000.

But if an actual pixel having distinct RGB values were supplied,
it wouldn't have worked right as just the low char was being
written to the destination buffer's bytes.

Additionally I think the til_fb_fragment_t.{pitch,stride} members
should probably change to the number of pixels (uint32_t) vs.
bytes.  The thinking initially was to facilitate describing
fragments having rows split up with arbitrary numbers of bytes.

Having a constraint of requiring the pixels always be 32-bit
aligned ensures dword-at-a-time optimized copies can always
succeed without something like SIGBUS occurring.  When such a
constraint is respected, the pitch/stride will always be 32-bit
aligned so they should just describe numbers of pixels.

Except, one can imagine scenarios where writing bytes at a time
instead of uint32_t's at a time can produce interesting
color-staggerring effects, and introducing a deliberate offset in
the pitch/stride making it unaligned can be interesting.

I'm leaving it all alone for now, but there's already assumptions
being made about doing uint32_t-grained operations on the
fragment's buf.  Even the til_fb_fragment_t.buf's type is a
uint32_t* already, and it forces us to use a void* or char*
version of the pointer to apply pitch/stride as in this commit.

0 files changed, 0 insertions, 0 deletions