I am not familiar with that graphics software on that unit, but I am familiar with other graphics systems.
The normal approach is to have a "drawing window" in memory that the pixels are "painted" to.
Drawing starts with clearing this, filling in the background, drawing buttons and text.
Then that memory is copied to or swapped with the actual "video buffer memory" that is being displayed on the screen.
Then, periodically (20 Hz, 25Hz, 60Hz or when a graphics element changes) the whole process is done again, with a new background/widget/text and so on.
So the WHOLE THING is redrawn, from scratch, every time through some sort of timed loop, or (as an optimisation), only if some data has changed that requires something on the screen to change - different text, number, colour of something, position of a needle and so on.
Otherwise, if you aren't "redrawing the whole thing", then you have to wipe out or repaint the areas that are changing. That would involve a rectangle around the text-box you're drawing. That rectangle needs to be cleared (to the background colour or the background of the text box) and then the new text is drawn. I don't know how many of those actions the "D4D_LabelSetText()" function performs for you, but it may assume something else painted over the previous next so the new text could be literally "drawn on a blank canvas".
Have you read the guide in this post, and the link to the Reference manual?
https://community.nxp.com/docs/DOC-330064
The above points to this, and I note the following comment, which means SOMETHING has to be called to redraw the screen:
The macros with _INRAM postfix creates complete graphic objects in RAM memory and thus all parameters can change runtime, but the screen must be redrawn manually after each change.
http://gargy007.github.io/egui_doc/egui_description.html
Tom
