Hi,

Depending on the font type and anti-aliasing level you are using, it definitely can take longer to display a string compared to a simple rectangle that is not anti-aliased.

If the font is anti-aliased, the semi-transparent parts are mixed with the background colors. And obviously, the bigger the font is, the longer it takes to display each character bitmap.

Best regards,
Florian

Dear Yuki,
The following contents are just my thoughts. I am also novice for enWin library. Please keep this in mind as reference..

I think DrawRect is a very simple function. This is because all you have to do is write data while comparing the start and end regions.
I think FillRect is also a very simple function. Firstly set area with the start point and end point area on the LCD and just send the color data(for ex, 16bit 565) as amount of the set area size.
However, the string function will take more time to take each character data from the selected font data table and write a pixel while comparing it to each pixel using options like transparency or anti-aliasing. So comparing with string fn and simple drawrect or drawbmp, it seems take more time.

As Florian said above, bigger font will need more processing time to display.
BR,
Tommy Lim

Hi Yuki,

GUI_AA_SetFactor() sets the AA factor for drawing operations such as GUI_AA_DrawRoundedRect(), and so on. This does not refer to strings.

You would need emWin fonts of the type "Extended", not "Extended, antialiased, 2bpp" or "Extended, antialiased, 4bpp". You can create your fonts using the Font Converter.

Best regards,
Florian

Hi Tanaka,


The reason for the slow drawing performance might be the following.

Strings are getting drawn as bitmaps. These are getting drawing most likely line wise causing quite some traffic on the bus. Depending on the drawing mode emWin also has to read back pixel data from the display causing even more traffic.

To reduce the traffic you can use a buffer, either a cache or a memory device. Instead of writing line wise to the display emWin will complete the drawing operation in the buffer and, once done, sending the buffer in a whole.

Which driver are you using?

Depending on the driver you can use a display cache.

If the driver doesn't offer a cache you can use memory devices to buffer the text output before sending it to the LCD. Of course, both methods require some memory.

A cache can be enabled by configuring the driver (most drivers except GUIDRV_Lin). Just take a look into the emWin manual to find out more about your driver and how to enable a cache. Such a cache requires memory (obvious). The memory equirement is calculated most likely like:

xSize * ySize * color depths in bytes

Depending on the color depths might be different (for 3bpp it would be strange to allocate an entire byte...).

Just make sure you have given emWin enough memory (GUI_ALLOC_AssignMemory()).

The second option is to use the window manager create flag WM_CF_MEMDEV. This applies only if you are using the window manager and widgets. Any drawing operation of a window happens in WM_PAINT, with the WM_CF_MEMDEV flag set this rawing operation will be performed into a memory device before it gets actually drawn to the LCD.

Memory devices also require memory, but the don't need as much as the cache. emWin tries to create a memory device as large as the window which shall be drawn. If this is not possible emWin splits the drawing into multiple parts. But still, this will most likely increase the performance.


Attention! For those who are reading these line, memory device do not improve the performance in general! Only in certain circumstances memory devices can be used to improve the performance (like in this case).

Best regards,
Sven