Interesting, I sent this through the "Disassembler" in EAB and put it after a little editing into EVE Screen Editor now. :-)
So, evidently you are using a 800x480 panel in portrait mode.
Correct.
A couple of image in ARGB that are located in RAM_G - these would need 1/8 of memory in ASTC 8x8 and probably less time to transfer depending on if you are using CMD_INFLATE and what compression ratio can achieved with the images.
I'm actually currently working on migrating the majority of our images over to flash as we had managed to nearly fill RAM_G. This also greatly reduces our boot time since we're not using CMD_INFLATE at initialization for all the graphics.
You are using a font that is stored in FLASH.
Have you tried using a ROM based font to see if that makes a difference?
Yeah, we're using the Roboto font to align with a corporate style guide. I hadn't considered using one of the ROM fonts, good idea.
The first thing that is drawn is a rectangle across almost the entire screen - why?
Next you draw a second rectangle, setting the line-width again and using BEGIN(RECTS) again is not necessary.
Style guide once again. We're supposed to have a thin (5 pixel) border around the screen, but in reality it's barely visible and the large rectangle could be eliminated. The second rectangle is drawing a header across the top of the screen. This is all really old code for the project and before I really knew how the display list worked; hence the unnecessary begin-rects and redefinition of the line width. I've attached a screenshot.
Speaking of BEGIN(), there is only a single END() at the very bottom - and I believe it has no effect down there at all.
While it might not be necessary to set an END() for every BEGIN(), it is recommended to do so in the programming guide.
I'll make sure to address that, thanks!
Then you draw 12 grey points.
Draw four rectangles and set the line-width and BEGIN() only once.
Draw four images over the rectangles and probably used EVE_cmd_setbitmap() to do so as this is happening a tad bit inefficient.
Next the color is set twice to white - for good measure? :-)
A larger image is placed, a row of text printed to the bottom.
One of the 12 grey points on the top is overwritten with a green point of the same size.
Two small images are placed, a green rectangle is drawn in the bottom right, an image is place on top of the rectangle.
A small bitmap is transformed and placed.
There's a series of navigation dots drawn across the top to indicate which page a user is on. We also have four user-defined buttons across the top of the screen which those four rectangles and icons define the function of. Perhaps wrongly so, the code is written such that the placement, width, etc can all by dynamically defined so there's some weirdness in how and when certain objects are defined. The button icons are also used elsewhere on some pages so it didn't make much sense to create an image that could duplicate what the icon and rectangle could accomplish. Some of this is defined as part of the static background so SPI communication wise it's actually not as bad as it looks.
The code is also structured such that different elements are drawn within different functions and/or objects so I'm not too surprised we really hammered that we wanted the color white.
The grey dots and green dot are handled differently in code. The grey dots are drawn as part of a static display and stored in RAM_G to be recalled when the main display list is defined while the green dot is drawn dynamically with every screen refresh to indicate which page the user is on, hence one gets overdrawn.
A slightly longer text is written in three rows - have you tried to split this into three separate CMD_TEXT?
So this is an interesting one. I was relying on the newline character to help with text wrapping and reduce how many commands we needed to send, but now that the vertical height of the font has changed since I've added more characters for language support there's too much space between lines and I will be splitting this into three CMD_TEXT. Since this element seems to be what's causing the display list to crash (I'm not certain of this) I suspect the change may indirectly resolve our problem.
I would say that this can be tweaked to be more efficient but then it looks like this is not what you are actually using,
this looks like a slightly reduced version as there are no touch tags set for example.
We don't utilize a touch screen so what you see is the full display list. As I hinted at earlier there are some elements stored to RAM_G as a static display list so while the list itself looks pretty cluttered, in terms of SPI communication overhead it's not as bad as it looks.
Oh, years you say?
I changed quite a lot in the last, well, years, including the coprocessor fault recovery.
We're probably overdue for some updating.
In all honesty everything had been working pretty darn well up until recently.
(On a side note, is every single post seriously limited by moderator approval or is there just a probationary period?)