Reverse byte order option for GUIX Studio about guix

[jdeere5220]

Hello XuNeo,

Yes, it's intentional that this option converts to BGR order, that's the hardware requirement that we have sometimes seen. To reverse the bytes as you describe sounds like more of a big-endian/little endian type change. Did you try turning on the BigEndian option?

I will enter a task to review the low-level functions and be sure they are using the ASSEMBECOLOR macro as they should. However I believe the bigger issue is the format of the pixelmap data produced by GUIX Studio. The ASSEMBLECOLOR macro isn't always used, especially if we are writing a solid color or rendering a glyph or pixelmap data with no alpha. In that case it's a straight write, and the source data would need to be in the desired format. This I believe requires a change on the GUIX Studio side.

I'm hoping that turning on the BigEndian option will give you want you want. Can you try that and report back please?

Best Regards,

Ken

[XuNeo]

Hi Ken @jdeere5220 ,

Yes, I have tried the BigEndian option. But it won't work:

1. For compressed bitmap, it definitely won't work because data is not the original bitmap.
2. For non-compressed bitmap, it doesn't work and it seems like GUIX Studio's bug. The generated data won't change whether Big Endian box checked or not.

Ideally, GUIX Studio generates desired format of resources and source code checks data format and do conversion using macro.
I think to solve the 'byte order' issue, another color option like 3G_5B_5R_3G could be added and follow existing method dealing with BGR565. 3G_5B_5R_3G is just a byte-order reversed of RGB565, explanation below from LVGL.

typedef union {
    struct {
#if LV_COLOR_16_SWAP == 0
        uint16_t blue : 5;
        uint16_t green : 6;
        uint16_t red : 5;
#else
        uint16_t green_h : 3;
        uint16_t red : 5;
        uint16_t blue : 5;
        uint16_t green_l : 3;
#endif
    } ch;
    uint16_t full;
} lv_color16_t;

Regards,
Neo

[jdeere5220]

Hello XuNeo,

OK I will put this on our roadmap to support this format. I'm not sure how quickly we will be able to get to it, there are a few other things in front.

Best Regards,

Ken

[yuxin-azrtos]

Close this issue.