Appwizard performance issues

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

    • Appwizard performance issues

      I'm having performances issues using emwin/appwizard, and i cant figure out if it is expected from that type of configuration with this type of hardware, or if i'm missing something.

      Our client developped the interface using Appwizard, so we wouldn't have to modify our code every little design change.

      Hardware is:
      180MHz cortex M4F (LPC54607)
      2Mbytes SDRAM 16bits @90Mhz
      800*480 24bits display

      I am using double buffering with GUIDRV_LIN_16 with GUICC_565.

      so about 1.5Mbytes for vram, and 500kBytes for emwin memory.

      emwin execution is from external qflash with eXecute In Place

      all ressources are also on the flash (not enough flash in the uC).

      Im running RTOS but there is no other task than this GUI task

      The screen that showed me there was a problem has:

      - 5 boxes
      - about 50 text
      - 7 images (about 100*100) each

      when this screen is the first screen to load, it takes about 25 seconds to load.

      When this screen is not the first one, it takes about 2m40s to load. same screen.

      I was puzzeled so i tried with emWin without appwizard, the temperature control example.

      reaction is quick, I'd say about 80-100ms. the screen is pretty full of elements aswell.

      with the example i was able to test with emWin lib in CPU flash, it was a bit faster, but not by that much.


      I am starting to beleive that the Appwizard eventloop costs way too much time to execute because of the "runtime configuration" aspect.

      so first question is:

      Is that the kind of speed that you expect from this configuration and this hardware?

      and if it is not, do you have any idea how i can debug the reason of this slowness?



      we are really trying to not have to redesign the interface using only EmWin (project has around 12 screen and 300 objects)


      I hope you are able to direct me to a fix


      Best regards,

      Alexis Marquet
    • Hi,

      Indeed this seems to be pretty slow.

      I could imagine that the image format has a big impact on the performance.

      Try the following:

      Click on the Image button in the lower left corner of the AppWizard. This will open the Images dialog. In the 'Format' column the format of the bitmaps is set to 'Auto'. You can change this.

      If an image uses 32bpp but the target uses only 16bpp the AppWizard converts the images into an 16bpp format which has also one additional byte for alpha values. Unfortunately, this format is not the best in regards of performance.

      You can change the format manually to a pure 16bpp format, for example 'High color (565)'.

      Of course, this will remove any transparency from the bitmap. So, it might be necessary to modify the original images to have a solid background.

      Another reason can be the flash memory where the resources are located on. I already had some issues in the past with really slow flash memory.

      Also, your CPU seems to be not that fast, especially with a screen of 800x480 pixels.

      Anyway, at first I would try to change the image format.

      Regards,
      Sven
    • Thanks a lot for your answer,

      I was able to change the format, first to "high color 565", with no noticable improvement, and then with auto, with a 10s improvement (going from about 25 to about 15 seconds) when the screen in question was the first one.

      That led me to try this with the screens order the "original way", and again, load time was decreased by about 10seconds, from 2 minutes 40s down to 2 min 30s.

      That problem is still not clear to me, why loading this screen first or loading this screen 4th would lead to such a different load time.

      I wanted to try the GUIDRV_NULL that is discussed briefly in EmWin UM but that driver does not seem to be available without source code.

      I looked into the flash being too slow, and with the temperature control, i was able to fit it in memory on chip and there is a slight improvement compared to execution off chip. The flash running with a clock at 96MHz in quadSPI, so it doesn't seem to me like that would be the bottleneck. again, there is a slight improvement running from internal flash, but nowhere near the kind of factor that would make this usable...



      and when you mean "your CPU seems to be not that fast, especially with a screen of 800x480 pixels", i could understand it two ways:
      1. the CPU seems to be running slow compared to the specs given
      or
      2. the chosen cpu specs seems too low, considering the 800x480

      which were you thinking?


      I was thinking that the problem was transparency (since multiplication for each pixel might add a lot of processing time), but that does not seem to fix the problem

      I hope we can narrow it down,

      Best regards,

      Alexis Marquet
      Hepia
      Switzerland
    • Hi Alexis,


      alexis.marquet wrote:

      That led me to try this with the screens order the "original way", and again, load time was decreased by about 10seconds, from 2 minutes 40s down to 2 min 30s.
      This seems to be way too long. Unfortunately, I have no idea why this might take that long. The only thing I could imagine right now is the image format.


      alexis.marquet wrote:

      2. the chosen cpu specs seems too low, considering the 800x480
      Yes, an MCU running with 90MHz seems to be slow for a screen of that size.

      Without being able to debug this issue it is really hard to help.

      Regards,
      Sven