Efficiency of redrawing fonts on labels

[naftilos76]

Hi,

I would like to ask whether the redrawing of the labels means erasing the whole previous contents area with the selected background color or updating only the new or different chars or even comparing bit by bit every char with the previously one drawn. I initially tried drawing with gdispDraw.... lines, text etc and i noticed that a frame-like-dropping artifact was visible when i drew a black filled rectangle over the previously drawn text and then the new text on that area. So what kind of updating is going on on labels when a new text is drawn on it? Is there any margin of improving especially when updating 20 or 30 strings of 5-6 chars each?

Regards

naftilos76

[Joel Bodenmann]

Redrawing any GWIN widget does indeed clear the entire widget are with the background color and redraw from ground up. The label does the same. To optimize this, you'd need to know the current content of your display memory and with most setups you don't do that (no double buffering). You'd first have to read back that pixel and then decide if it would need to be updated or not. Just redrawing every pixel is way more efficient there.

However, usually you don't redraw yourself anyway. The widget recognizes itself when its content changed. As soon as you call gwinSetText() on your label, it will update while the others stay the way they are.

~ Tectu

[naftilos76]

Hi Tectu,

Thanks for your prompt response. Your answer cleared things up. I will test the case of having multiple labels at a redrawing rate of 5/s and will give you my feedback. I have written my own code for drawing texts and updating only the chars that are different even if the different ones are the second and the 5th and so on.

For example:

1st: 0.6754Vrms (first update - all chars drawn)

2nd: 0.6655Vrms (second drawing - only elements 3 & 5 will be updated)

This however requires as you correctly stated double buffering and preferably malloc which however requires special handling in ChibiOS.

Using gwin labels doesn't let me draw on them but only if i do not use windows at all and restrist my calls only to gdispDraw...

That would need integrating the code in uGFX.

When i try the labels i will give you my final feedback regarding whether i can see any frame-dropping artifacts.

Thanks for your time

Regards

naftilos76

[Joel Bodenmann]

Maybe it would be a nice idea if we'd introduce some value widget. It would be like a label widget, but you can only display digits. You give it the amount of digits before and after the decimal point and then you can simply display integer values. It can then recognize the changes very easily and just update the changed ones.

Let me know about your results.

~ Tectu

[naftilos76]

Hi Tectu,

After a few tests i noticed that no matter what the speed of the mcu gwinSetText() did let me see some frame-like-dropping artifacts. That of course is due to the gwinFillArea() that's probably used to wipe off the area of the char(s). Playing a little with my own routine, which double buffers and remembers what the previous string was, i got no artifacts as well as no noticeable reduction in refreshing speed. It is easily understandable that this concerns mostly the usage of fixed-width fonts while variable-width fonts can still be used with this method and eliminate the frame-like-dropping artifacts. That is definetely something that has to be integrated into ugfx because it simply can help increasing its' performance and fans.

The code is a little messy. I have used it in the past with some fonts of mine generated by a win app generator. I have attached all of them for anybody's reference willing to explore it's functionality.

Regards

naftilos76

gstr.zip

[inmarket]

Sorry for the late reply to this thread.

This area of uGFX is fast evolving and there are a number of competing requirements.

On one hand uGFX gets run on some CPU's with very little RAM - so generally buffering display area's is a big no-no.

On the other hand - we used to have progressive, non-frame effect text fills with the old fonts code. Whilst it didn't optimize out overdrawing of pixels (which is not possible without buffering or display read-back), it did update in a smooth manner - filling as it was drawing each changed character. For unchanged portions of the text there was no visible display change.

This capability was dropped when converting to the mcufont library simply because of the complexity of the code required due to mcufont supporting kerning.

I am currently doing major work in the basic GDISP library and drivers which will include significantly reduced stack usage, significant performance optimisations, support for multiple displays, support for area streaming (as might be used by video). I will look at re-implementing the progressive text filling as I go as it definitely a nice feature.