I still have no idea what "issue" you are trying to fix in the first place.

Given that the resulting display list is within 8kB - and you always have to make sure it does - I can think of no issue, even when you try to rebuild snippets for the display list over and over.

Even if you just placed your display-list for build from snippets thru the co-processor and immeadiately after this
issue more commands thru the co-processor to update the snippets, it does not matter since all commands are executed sequentially anyways.
You need to make sure that you are not overloading the FIFO but again, you always need to take care of that and since the co-processer is rather fast when processing the FIFO you really would need to put some effort into racing it.

So I guess you could write display-list snippets directly to RAM-GL but not only is this a bad idea on its own, you could easily check if the co-processor is still busy with the display list.
Since you must not try to swap the display list faster than it is displayed, you can easily refresh the snippets in the 17ms you are not refreshing.

The argument that a display list could be without an update for a whole whopping frame is void when you put the updating of the snippets right before building a new list every 17+ ms.

And on top, why do you refresh your snippets anyways?
Everytime you do you could as well send the exact same commands thru the co-processor instead of using cmd_append afterwards, the SPI traffic sure is a little lower, but only for all the frames you do not refresh that snippet.
It more or less only makes the amount of SPI traffic unpredictable and you need to make sure that your programm is still running as it is supposed to in the worst case.

Saving memory could be raised as reason to refresh the snippets.
But first off the display-list is only 8kB long.
How many times that do you need in snippets to make it a problem?
And since for a example a button uses a different amount of memory if displayed normal or flat, you would either allocate the maximum amount for the snippet or implement some memory management.
Investing a little memory to pre-calculate two different snippets would be easier in this case.
And avoid using cmd_button in favour of two button images would make both snippets significantly smaller.
Plus since we are talking about EVE3 you could as well pre-calculate the snippets, put them in the FLASH and then use cmd_appendf to place the snippets from flash in the display-list.

I am afraid that you spent a whole lot of time solving something that is not an issue in the first place.

Hrmm, you know that the display-list is doubled buffered and only gets used to actually display anything if you tell it to?

You can use the co-processor to generate as many fragments of display lists as you like and take as much time
as you like to copy these around.
The display list is always updated asynchronously.

https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G/tft.c

This is just my ugly test-code and it is a bit outdated.
But I always have a function initStaticBackground() in which I define the portions of the screen that do not change.
and append this at the start when building the display list.
In my last project I expanded this to three segments, two additional ones to switch between two screens.

Looks like this is the place to put something like this, I have a code Library up on Github for a while now:
https://github.com/RudolphRiedel/FT800-FT813

Despite the name it supports BT81x as well.
I just finished a project for which I replaced a defective VM800B50A with a RVT50AQBNWC00.
This unit was driven by an Arduino mini-pro using the Arduino framework.
And in parallel I was testing the exact same display code on an EVE3-50G using an ATSAMC21E18A board with SPI by DMA.

Edit:
I just released the first interation of V5 of my code library:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x

I played with the new animation support in the EVE Screen Editor.
And I wonder what this is supposed to be used for.

Splitting up the frames of an animation into tiles is nice to save space in the external FLASH I guess.
Although the converter doubles the amount of frames and all the odd frames look exactly the same than
the even ones, so I have to wonder if this really is saving memory.
Without more insight I call this a bug in the converter.

There is a huge issue however, due to the tiling of the frames the display list is getting filled rather fast.
Now the smallest off-the-shelve FLASH on a BT81x module is 32MBit and I can easily replace it.
But the size of the display list is still only 8kB or 2048 commands.
The 124x300 pixel animation I have up in the EVE Screen Editor fills up the RAM_DL to 28% with only four lines
of coprocessor commands.

Am I missing something important here?
Right now this looks like a feature I rather not use.
Just cyling thru images on my controller has zero impact on the display list and while this costs a couple
more lines of code I just got a lot of free space for moving the images into the external FLASH.

And I checked, there is no way to tell the animation converter to drop the tiling.

Hi,

has anyone successfully implemented vararg functions for CMD_BUTTON, CMD_TEXT and CMD_TOGGLE?
I am looking into implementing it for CMD_TEXT and I am sort of stuck at the beginning.

The problem is, there is no way to tell how many arguments are supplied and of what type these are.
So if I understand this correctly you either have to work with a known set or arguments like numbers for which
you also provide the amount with which you are calling the function.

void EVE_cmd_text_numbers(int16_t x0, int16_t y0, int16_t font, uint16_t options, const char* text, num,...)

EVE_cmd_text_numbers(0,0,28,OPT_FORMAT,"foo bar %x.i",2,0xdeadbeef,8);

This approach seems lacking.

The other alternative would be to parse the string.
But then I could use snprintf() before using EVE_cmd_text() and be done.

A practical approach would be a function that adds a single uint32_t parameter that is transferred only if OPT_FORMAT is given.
Well, better than nothing, I am adding this for now.

I'm trying to load two converted png file from mcu flash but something is not right. How to know where to load next one image (display RAMG address) avoiding overwriting previous image?

How can you not know the properties of the images that you converted to be loaded from flash? :-)

Loading some random image from a sd-card could be a challenge.
But even then you better make sure that they fit into the space you reserve for them before unpacking these to RAM_G.

this makes use of the GET_PROPS command

That is a good example for a function which is described not so good in the user-manual.
The C prototype "void cmd_getprops( uint32_t ptr, uint32_t width, uint32_t height);" implies that you are feeding
parameters into it, not that you can use it to retrieve parameters.
The way how this works and how the data could be acessed is described a little for cmd_getptr.

My problem is not that I do not have an alpha-channel.
My problem is that the alpha-channel in my pictures is 8 bit and EVE uses only 1 bit.

The file "test_original.jpg" is a portion of a .png saved with irfanview.
The file "test_ARGB.jpg" shows how EVE Image Converter converts it.

And here I could stop as unfortunately using a BT815 instead of a FT813 still is not an option for me.
I would like to switch from EVE2-70G to EVE3-70G but neither Mouser or DigiKey have these in stock.

But you are right, as can be seen in the file "test_ASTC4x4.jpg", this works much better.
At least in the EVE Screen Editor it does.
 

Sent out a bunch of files.