Problems with drawing speed

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

  • Problems with drawing speed

    Hello,

    I am using STemWin to add a fundamental GUI to existing hardware/software, but am running into some problems using GUI_Exec() and WM_Paint(). The code I am building on top of follows the 'single task system (super loop)' execution model. Every second the main loop calls a function that updates my display.

    The function does the following:
    1. sets the color of several text widgets to the color of the background
    2. removes several graph data objects from an XY graph
    3. calls GUI_Exec()
    4. updates the values of the text widgets
    5. updates the graph data objects
    6. sets the color of the text widgets to a visible color
    7. adds the graph data objects back to the graph
    8. calls GUI_Exec() again

    What I am trying to achieve is updating text and graph data every second. However, the widgets seem to take a very long time (much longer than 1 second) to undraw and draw. Could I be doing something incorrectly?

    I am also having trouble using memory devices. I would like to buffer everything on the display so that when a popup appears, the underlying content can be withdrawn. I have created the underlying content without using the window manager. However, I cannot seem to create a memory device that contains the entire 320 x 240 pixels display. The most I can store seems to be 1/4 of the display. Is this because insufficient memory has been allocated to emWin in GUIConf.c?

    Any help would be greatly appreciated! :)
  • Hi,

    More than 1 second is too long for this operation (of course, it might also depends on the device).

    Which device are using?
    Which display driver?
    I have created the underlying content without using the window manager.
    You might also want to try the automatic use of memory devices by the window manager. Either you set the flag WM_CF_MEMDEV on creation of a window or set it global with WM_SetCreateFlags(WM_CF_MEMDEV).
    Is this because insufficient memory has been allocated to emWin in GUIConf.c?
    If you there is not enough memory available to create a memory device with the desired size the GUI_MEMDEV_Create() function will return with 0. In this case you should increase the memory in the file GUIConf.c.

    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.
  • Hey Sven,

    Thank you for replying to my post and for the info. I am using the STM32F405xx with the SOLOMON SYSTECH SSD2119 display driver. I have since moved to using the window manager API and creating windows for my screen elements including a banner, menu, submenu, and soft keys.

    I override the callback functions for each window to draw what I need on the screen when the callback is passed the WM_PAINT message, and have GUI_Exec() called every second from a super loop. I have also made sure to enable automatic usage of memory devices for the window manager.

    However, there are many situations where I need to update certain windows immediately (such as on a button press). I do this by calling WM_InvalidateWindow() followed by a call to WM_Paint() on the appropriate window. I believe this should prompt the window manager to redraw the screen immediately--but unfortunately this still takes too much time. There is an appreciable amount of lag between the button press and the update to the screen.

    I am now trying to figure out where my bottleneck is so that I can optimize my code / find a solution.

    In general what is being redrawn is the menu and submenu when the user presses buttons to navigate (I also have data tables and graphs that need to be redrawn with update values, but I am more worried about getting menu/submenu navigation fast enough at the moment). Menus and submenus are made of rectangles and text for each item.

    In the overridden callback for the menu, I draw rectangles for each menu in the item, then fill each rectangle with text. This should be very quick, as there are no complicated calculations or large amounts of code that would slow down the callback. This suggests to me that the bottleneck is overhead with the window manager.

    Of note is that I am using transparent windows--so the window manager needs to redraw the background, which is an image widget--and that I am invalidating the entire window instead of just a rectangle using WM_InvalidateRect(). However there are many cases where I need the entire menu/submenu to be redrawn.

    Can you please help me figure out why the window manager is responding so slowly? My intuition tells me that it should not take this long to draw/redraw windows. Is there also a way I could submit a request for technical support to SEGGAR?

    Thank you so much for your time.

    Best regards,
    Vincent
  • I do this by calling WM_InvalidateWindow() followed by a call to WM_Paint() on the appropriate window.
    It seems that this is incorrect actually. From the documentation regarding system-defined messages (includes WM_Paint):

    "These kind of messages are sent by the GUI library. Do not send system defined
    messages from the user application to a window or a widget."

    I have tried using WM_Update() as a replacement, but it is still too slow. Is there another way to prompt the window manager to draw/redraw immediately that I have missed?

    ****EDIT****

    I've since disabled transparency, and now everything draws/redraws much more quickly! :thumbsup: However, I would like to use transparency so that I can show the background image through parts of the window that are not drawn. Are there any ways that I can optimize how the window manager redraws transparent windows?

    The post was edited 2 times, last by vincenttpowersight ().