Fix RGBA -> ARGB ordering in vgfont
GRAPHICS_RGBA888(r,g,b,a) currently packs into a uint32_t like "ABGR", but the unpacking function in graphics.c (here) expects the uint32_t to be packed in "ARGB" to produce its rgba[4] array of VGfloats.
I have no idea whether the fix here is correct, but I suspect this PR should be moved to https://github.com/raspberrypi/userland as I believe that's where this code is actually maintained? (i.e. https://github.com/raspberrypi/userland/tree/master/host_applications/linux/apps/hello_pi/libs/vgfont )
@popcornmix I see this old PR here without every getting any attention, even that the case is trivial? R and B functions/variables are clearly switched (typo?) here?
I just did a bit of digging, and it seems that https://github.com/raspberrypi/userland/issues/193 is closely related to this?
Yes this seems to be the fix for the linked issue, also suggested there.
Ah but the suggested solution also includes swapping the functions arguments r and b so that existing scripts (having required workaround included) depending on current order are not broken. However probably it is better to have the usually interned order r g b and communicating this clearly as API change? Would be more consistent after all.
so that existing scripts (having required workaround included) depending on current order are not broken
I guess that's going to be the potential problem with "fixing" this - has the API now been broken for so long that the current incorrect behaviour has been adopted as the "new API", and so would fixing it cause more harm than good? :man_shrugging:
I've never used, or looked at, any of this vgfont code, so I have no opinions either way.
I couldn't see this anymore, hurts my eyes 😄, so I opened the PR on userland: https://github.com/raspberrypi/userland/pull/628
Pardon?