Okay, so I studied @Chris-Kawa's answer again. And what hit me like a bolt of lightning is that what I was dreaming of doing is virtually nonsensical. Now I really understand what he was saying.
This is what I wished to make happen (when I was naive :D):
The background timer's timeout event, issues an update() command which draws immediately into the screen (like magic), which in turn, triggers a ~17ms single-shot timer.
When that timer's timeout occurs, the text shown on the screen is cleared immediately (again magic).
This keeps on looping till the user stops the background timer.
This is what actually happens:
Issue an update() command that "draws" the text (text is NOT shown yet). The single-shot timer (@~17ms) is triggered.
...probably some milliseconds elapsed (let this be x ms).
At the vertical refresh moment, text becomes visible on screen. (this is damn fast, so I'm ignoring this interval)
...probably some milliseconds elapsed (let this be y ms)
The single-shot timer has ended after ~(x+y) ms and a command to clear the text has been issued.
...probably some milliseconds elapsed (let this be z ms).
At the vertical refresh moment, text is cleared from the screen. (ignoring this interval again)
So, the user sees the text for about (x+y+z+k) ms where, k is the sum of the additional milliseconds used in actually doing that stuff. Now, x+y+z+k ms is almost always not equal to the desired interval.
That's why, this process sucks, big time.
Now, this is the best that can happen:
Wait for the background timer to end. After it ends, as soon as a refresh cycle occurs, issue the command to draw the text.
At the next refresh cycle, the text will be drawn to the screen. After the text is drawn, start the single-shot timer.
After the timer has ended, issue the command to remove the text. Wait for the next refresh cycle.
At the next refresh cycle, the text will be removed from the screen. Now, start the background time. Now go to the first step.
Visualizing the process,
Now, it is evident that showing the text exactly for 15ms is impossible using the previous method. But at least we can make sure that we don't show that more than ~32ms. And that's good news. At least in my case.
Now, the point is how to achieve that. I don't know. But I'll find you and I'll kill you, nay implement you.
I found addiotional regularity: problematic delegates have the same picture as last top delegate hidden during scroll down within ListView.
It seems scrolling out delegate from visible area forces it's image repaint in other delegates, which are in visible area.
This repaint seems to hide the text element, declered with z-order above the image.
Reset the visible property (visible=false, visible=true) at end of each scrolling (using onMovementEneded) solves the problem.
But, i don't want to pay the repaint price of such solution as my application is running on embedded device.