Dialog Navigation slow

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

    • Dialog Navigation slow

      Hello,

      I have a number of dialog windows for screens and navigate from one dialog to another. I had used RGB565 with multibuffering and Memdev enabled using WM_SetCreateFlags(WM_CF_MEMDEV) but observed dialog loading is slow. I call GUI_exec() continuously in my super loop while(1) to update the dialogs.

      I performed the following configurations below to check the dialog loading in each case.

      With WM_SetCreateFlags(WM_CF_MEMDEV) and #define GUI_BUFFERS 2
      - Navigation between dialogs is slow.

      Without WM_SetCreateFlags(WM_CF_MEMDEV) and #define GUI_BUFFERS 2
      - Navigation between dialogs is slow.

      Without WM_SetCreateFlags(WM_CF_MEMDEV) and #define GUI_BUFFERS 1
      - Navigation between dialogs is fast but all dialogs flicker a lot while loading

      With WM_SetCreateFlags(WM_CF_MEMDEV) and #define GUI_BUFFERS 1
      - Navigation between dialogs is fast when compared to first 2 options but still needs to improve

      Am using the last option above currently as it is fast when compared to other options.

      With some of the dialogs knob widget is present. if knob widget is removed then it certainly improves the specific dialog load speed
      I tried to use memdev for drawning bmp and rotate it using GUI_MEMDEV_Rotate to achieve similar functionality as knob but nothing was drawn on the LCD.
      Do you have any sample code which replicates the knob functionality but is fast when it loads. if yes then please share it.

      What can be done further to improve the load speed of the dialogs? and which is the best option to use from above options?

      Thanks
      Regards,

      Anuj Tanksali

      The post was edited 3 times, last by anuj.tanksali ().

    • Hi,

      typically it is not required to enable automatic use of memory devices.

      Automatic use of memory devices will produce an overhead in regards of drawing. At first emWin draws into the memory device and then the memory device gets drawn into the framebuffer. It can get even worst if there is not enough memory available to create a memory device for the complete window area. If there is not enough memory emWin uses banding and creates multiple small memory devices after each other till the complete window has been drawn.

      There are scenarios where this might come in handy (not enough memory for multi buffer or a cache) but it still has the disadvantage in regards of the drawing overhead.

      The first option to avoid flickering effects should be multibuffering (GUIDRV_Lin) or a driver variant with cache (e.g. GUIDRV_FlexColor).

      Also, there is no connection between memory devices and multibuffering.

      I recommend to set the number of buffers for multibuffering to at least 2 (faster would be 3 because the application doesn't has to wait for a VSYNC interrupt) and to not create windows with the WM_CF_MEMDEV flag.

      Please note that a memcpy operation gets performed before the first drawing operation into the backbuffer. emWin copies the current frontbuffer content into the backbuffer to make sure their content is identically before drawing.

      Depending on the screen size and the speed of your MCU this might slow down the application. You can try to set a custom copy buffer function and use the DMA to copy the front into the backbuffer.

      Take a look at the function LCD_SetDevFunc() which allows you to set a custom copy buffer function

      segger.com/doc/UM03001_emWin.html#id_003093

      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.
    • Hello,

      Thanks for the reply.

      I have already used the LCD_SetDevFunc() to set the custom copy buffer function.
      I will check the DMA option.

      Will using 3 buffers cause an improvement in speed regarding dialog loading?

      As mentioned above the knob widget seems to slow down dialog load quite a bit.
      Can we achieve the knob functionality with some other methods like memdev for drawing the bmp and memdev_rotate for rotating the bmp.
      if there is any sample project please share it.

      Thanks
      Regards,
      Anuj

      The post was edited 1 time, last by anuj.tanksali ().

    • Hi,


      anuj.tanksali wrote:

      Will using 3 buffers cause an improvement in speed regarding dialog loading?
      Not sure if it will reduce the loading.

      The KNOB will create 32bpp memory devices. THis means that every pixel needs to be converted into the framebuffer format which is 16bpp. I could imagine that this takes a while on a hardware without hardware acceleration. Of course, this depends also on the size of the KNOB.


      anuj.tanksali wrote:

      Can we achieve the knob functionality with some other methods like memdev for drawing the bmp and memdev_rotate for rotating the bmp.
      Unfortunately not. The only way I could think of is to store multiple images which will represent the rotating element (one image for every position, like a movie).

      You could also reduce the moving part to just a marker moving over a static background. This way you would only need to rotate the marker bitmap. On the image attached it is just the little green marker which is moving.

      Here you will find an example regarding rotating a memory device:
      wiki.segger.com/Memory_Device_-_Rotate_(Sample)

      The KNOB is obsolete in newer emWin versions. Since version 6.10 we have a ROTARY widget which does more or less the same. Here is an example:
      wiki.segger.com/ROTARY_(Sample)

      Regards,
      sven
      Images
      • Rotary.png

        20.61 kB, 138×67, viewed 712 times
      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,

      Of course you can rotate it by using memory devices.

      wiki.segger.com/Memory_Device_-_Rotate_(Sample)

      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.
    • Hello,

      Thanks,
      I checked out the above link and will try it.
      There is a onpaint function for the dialog so the above code should go in onpaint or in my normal superloop while(1)? as we have to rotate the bmp at runtime depending on angle.

      If there is anything else we can try to achieve good performance with 2 buffers and without WM_CF_MEMDEV set please let me know as using 2 buffers is still slow. Am using iMXRT1064 controller. is there anything on the controller side which can be done other than DMA?

      Thanks
      Regards,
      Anuj

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

    • Hello,

      I tried out as per the link given but facing some issues. I have made a function which does the task of writing to memory device.

      My code is as below,

      static GUI_MEMDEV_Handle hDst = 0;
      static GUI_MEMDEV_Handle hSrc = 0;
      int xSize = 235;
      int ySize = 235;

      hSrc = GUI_MEMDEV_CreateFixed32(0, 0, xSize, ySize);

      GUI_MEMDEV_Select(hSrc);

      GUI_DrawBitmap(bmdial , 0, 0)

      GUI_MEMDEV_Select(0);

      hDst = GUI_MEMDEV_CreateFixed32(0, 0, 500, 500);
      GUI_MEMDEV_Select(hDst);
      GUI_SetBkColor(GUI_TRANSPARENT);
      GUI_Clear();
      GUI_MEMDEV_Select(0);

      GUI_MEMDEV_RotateHQHR(hSrc, hDst, 100, 400, 45 * 1000, 1 * 1000);

      GUI_MEMDEV_WriteAt(hDst, DIAL_SCREEN_HOME_ARC_CENTER_POS_X-(235/2), DIAL_SCREEN_HOME_ARC_CENTER_POS_Y-(235/2));

      GUI_MEMDEV_Delete(hSrc);
      GUI_MEMDEV_Delete(hDst);

      the above function is called in my loop which is called every 25msec.

      I also have a onpaint which draws other stuff as below,

      GUI_SetBkColor(GUI_GRAY)
      GUI_Clear()
      drawArc();

      other point is am testing this on my hardware with iMXRT1064 controller.
      If I call the above function in my super loop on 25msec then it does not draw.
      I called the function in onpaint after GUI_clear() above as below

      GUI_SetBkColor(GUI_GRAY)
      GUI_Clear()
      drawDial();
      drawArc();

      then it draws when I single step through the code. after drawing the bmp, when GUI_exec is called the whole screen becomes blank.

      Please let me know what am missing?

      Thanks
      Regards,
      Anuj

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

    • Hello,

      I was able to display the bmp and rotate it through memdev. I created the memdev's required in a different function, performed the rotate and kept the memdev ready. I displayed the memdev in WM_PAINT by GUI_MEMDEV_WriteAt function

      GUI_SetBkColor(GUI_GRAY)
      GUI_Clear();
      GUI_MEMDEV_WriteAt(hDst,DIAL_SCREEN_HOME_ARC_CENTER_POS_X-(236/2), DIAL_SCREEN_HOME_ARC_CENTER_POS_Y-(236/2));
      drawArc();

      This is working but the screen loading performance is not improved much. My main intention is to improve the dialog loading performance so used memdev for rotating the bmp instead of knob widget. I thought this would improve the dialog loading but not much improvement.

      if I comment out the code for drawing and rotating the bmp the dialog loads faster.
      How can I improve the memdev drawing so that it loads faster?

      Thanks
      Regards,
      Anuj

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