Hide/unhide parts of the content

[theSwiftGuy]

Hi,
I am thinking if is possible somehow, to hide or unhide an icon, or to change the color of a text, without modifying the entire content.
In this scenario, my background is black, and the icons are white. If I want to deactivate an icon, I am thinking that changing the color into black will do the job.
In order to have control of each component, can I use the append method for each component individual ?
As example, I have 6 icons, and each of them can be on or off. I start the display with them off. I go into settings menu, and activate on of them. When I return, I expect to see that icon on. in this scenario, what could be the best approach?
I am thinking to use like a static method for each state. I create the method for icon when is On, another method for when if Off, for each methods I get the ram address as return, and when I run the content, and switch to other state, I only append the specific ram address into the display list. Could be this a solution?

[RudolphRrr]

Yes, CMD_APPEND can be used for that.

A block of commands added with CMD_APPEND could be:
BEGIN(BITMAPS)
CMD_SETBITMAP(0, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
COLOR_RGB(170, 170, 255)
VERTEX2F(2320, 4288)
END()

or if this for a groups of icons:
CMD_SETBITMAP(0, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
COLOR_RGB(170, 170, 255)
VERTEX2F(2320, 4288)

CMD_APPEND needs 12 bytes.
CMD_SETBITMAP needs 16 bytes.
COLOR_RGB, VERTEX2F, BEGIN and END need 4 bytes each.

So in this scenario using two snippets with different colors would remove 20 or 12 bytes of traffic from the SPI per icon but would also add 64 or 48 bytes to RAM_G per icon.

And adding a touch-tag increases the saving on the SPI by additional 4 bytes with 8 bytes of cost in RAM_G.

I usually just go with changing the colors on the fly but then I usually do not need to reduce the traffic on the SPI to a bare minimum.

Bad example of what I did in a project as this would not benefit from using CMD_APPEND:

EVE_cmd_dl_burst((DL_BEGIN | EVE_POINTS));
EVE_cmd_dl_burst(POINT_SIZE(150));

EVE_color_rgb_burst(LIGHT_GREEN);

if(vl1_delay)
{
    vl1_delay--;
    EVE_cmd_dl_burst(VERTEX2F(330+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}
if(vl2_delay)
{
    vl2_delay--;
    EVE_cmd_dl_burst(VERTEX2F(370+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}
if(vl3_delay)
{
    vl3_delay--;
    EVE_cmd_dl_burst(VERTEX2F(410+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}

...

EVE_color_rgb_burst(LIGHT_GREY);

if(!vl1_delay)
{
    EVE_cmd_dl_burst(VERTEX2F(330+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}
if(!vl2_delay)
{
    EVE_cmd_dl_burst(VERTEX2F(370+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}
if(!vl3_delay)
{
    EVE_cmd_dl_burst(VERTEX2F(410+LAYOUT_MODX3, LAYOUT_Y2+STATUS_LINE_1));
}

...

EVE_cmd_dl_burst(DL_END);

So I rather re-arrange the display-list to avoid sending duplicate commands.
Even if that means more and duplicate code on the controller.

So there is not really a best way to do this, it depends on the application what is good enough given the restraints.

[theSwiftGuy]

In my case, if my display is without touch, I will not use the TAG.
It could be useful, if there is something similar with TAG but for general purpose, in order to use it for hide/unhide things.