I'm not sure whether to laugh or cry.
-
I fixed a bunch of bugs in terms of color byte order (I had switched from RGBA to ABGR) which I hoped would fix my SVG rendering, whose colors are off. After finding and squashing a bunch of bugs (and watching the colors change accordingly) the last bug I fixed put my output clear back where I started! So that was my morning. :doh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I fixed a bunch of bugs in terms of color byte order (I had switched from RGBA to ABGR) which I hoped would fix my SVG rendering, whose colors are off. After finding and squashing a bunch of bugs (and watching the colors change accordingly) the last bug I fixed put my output clear back where I started! So that was my morning. :doh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I fixed a bunch of bugs in terms of color byte order (I had switched from RGBA to ABGR) which I hoped would fix my SVG rendering, whose colors are off. After finding and squashing a bunch of bugs (and watching the colors change accordingly) the last bug I fixed put my output clear back where I started! So that was my morning. :doh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Why you switched from 'RGBA to ABGR'? From what I remember, 'ABGR' is really a native Windows API thing, which has even corrected with wpf.
It's not windows. (Well, it can be, but it's embedded/cross platform) It's based on the fact that the plutosvg library I used uses argb and rgba but LITTLE ENDIAN overall. The thing is, since shifts are reversed for big vs little endian in C/C++ big endian RGBA = little endian ABGR My graphics library produces big endian footprints for pixels on little endian systems. The reason for that is almost all display hardware takes its frame buffer memory in big endian format. I'd change plutovg to use big endian pixels but I don't understand this function:
static inline uint32_t BYTE_MUL(uint32_t x, uint32_t a)
{
uint32_t t = (x & 0xff00ff) * a;
t = (t + ((t >> 8) & 0xff00ff) + 0x800080) >> 8;
t &= 0xff00ff;
x = ((x >> 8) & 0xff00ff) * a;
x = (x + ((x >> 8) & 0xff00ff) + 0x800080);
x &= 0xff00ff00;
x |= t;
return x;
}The exception would be things like a windows PC, * but * in that case it's 1 byte per pixel, making swapping them easy, whereas byte swapping a 16-bit RGB565 pixel is less straightforward. So since plutovg is RGBA little endian, my vector pixel format is ABGR big endian. In my library, conversions between different pixel formats is transparent so it really doesn't impact the surface area of the API.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It's not windows. (Well, it can be, but it's embedded/cross platform) It's based on the fact that the plutosvg library I used uses argb and rgba but LITTLE ENDIAN overall. The thing is, since shifts are reversed for big vs little endian in C/C++ big endian RGBA = little endian ABGR My graphics library produces big endian footprints for pixels on little endian systems. The reason for that is almost all display hardware takes its frame buffer memory in big endian format. I'd change plutovg to use big endian pixels but I don't understand this function:
static inline uint32_t BYTE_MUL(uint32_t x, uint32_t a)
{
uint32_t t = (x & 0xff00ff) * a;
t = (t + ((t >> 8) & 0xff00ff) + 0x800080) >> 8;
t &= 0xff00ff;
x = ((x >> 8) & 0xff00ff) * a;
x = (x + ((x >> 8) & 0xff00ff) + 0x800080);
x &= 0xff00ff00;
x |= t;
return x;
}The exception would be things like a windows PC, * but * in that case it's 1 byte per pixel, making swapping them easy, whereas byte swapping a 16-bit RGB565 pixel is less straightforward. So since plutovg is RGBA little endian, my vector pixel format is ABGR big endian. In my library, conversions between different pixel formats is transparent so it really doesn't impact the surface area of the API.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I fixed a bunch of bugs in terms of color byte order (I had switched from RGBA to ABGR) which I hoped would fix my SVG rendering, whose colors are off. After finding and squashing a bunch of bugs (and watching the colors change accordingly) the last bug I fixed put my output clear back where I started! So that was my morning. :doh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Three lefts make a right.
-
I fixed a bunch of bugs in terms of color byte order (I had switched from RGBA to ABGR) which I hoped would fix my SVG rendering, whose colors are off. After finding and squashing a bunch of bugs (and watching the colors change accordingly) the last bug I fixed put my output clear back where I started! So that was my morning. :doh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
the last bug I fixed put my output clear back where I started
Been there. Done that. :)
