GUI_DispString() performance is poor compared to GUI_DrawRect()

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • GUI_DispString() performance is poor compared to GUI_DrawRect()

      I'm trying to display text and graphics on the LCD.
      My wonder is that the text drawing performance is very poor compared to other graphics (rectangles).
      What is a bottleneck? Or is it inevitable?

      I found this post, but there is no solution yet.
      Font Draw Time/Performance

      My application is running intermittently due to low power consumption and only needs to be active for a short time.
      The LCD driver is custom and uses a bitplane driver.

      Here are some examples:

      C Source Code

      1. GUI_SetFont (GUI_FONT_20_1);
      2. GUI_SetTextMode (GUI_TM_NORMAL);
      3. GUI_DispString ("AAAA"); // 3300us
      4. GUI_DispChar ('A'); // 800us
      5. len = GUI_GetStringDistX ("BBBB"); // 35us
      6. GUI_DrawRect (0,0, len, 20); // 185us :17 times faster than text
      7. GUI_FillRect (0,0, len, 20); // 305us :11 times faster than text

      MCU specifications:
      Cortex M0 48MHz
      32kB RAM, 256kB flash ROM

      Thank you.
      Yuki
    • 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
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • 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
    • Dear Florian and Tommy,

      Thank you for your quick reply.

      As you said, the bigger font takes longer time.
      I've tried that created font without anti-aliasing, but the speed wasn't change. Futher my display has only 3bit/pixel (RGB), and it seems to there is not heavy anti-alias processing.

      Although, It is not clear my setting is disable anti-aliasing completely.
      My current setting is only "GUI_AA_SetFactor(0);".
      How it disable completely?

      Best regards,
      Yuki
    • 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
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • 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.

      tanaka wrote:

      Futher my display has only 3bit/pixel (RGB)
      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
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.