emWin: Multi-buffering Optimization Question

[lsrbigfoot]

Hello,

This is a follow up to my previous post: https://community.nxp.com/t5/i-MX-RT/RT1170-EVKB-PXP-eLCDIF-LCDIFv2-and-emWin/m-p/1866522

I observed a significant reduction in execution time if I commented out the multi-buffering feature of emWin, at the cost of horizontal tearing effects, especially while changing the entire screen.

Before:

        if(condition)
        {
            GUI_MULTIBUF_Begin();
            GUI_Exec();
            GUI_MULTIBUF_End();
        }

After:

        if(condition)
        {
            //GUI_MULTIBUF_Begin();
            GUI_Exec();
            //GUI_MULTIBUF_End();
        }

After reviewing emWin Multi-Buffering - SEGGER Wiki, I think that "GUI_MULTIBUF_Begin()" is not as efficient with respect to copying frame buffers from front to back.

Is there a way to optimize "GUI_MULTIBUF_Begin()" or make it use a feature of the i.MX RT to copy the frame buffers faster?

[EdwinHz]

Hi @lsrbigfoot,

Seeing as this is an inquiry mainly regarding the functionality of a dedicated emWin routine, I would recommend you consult with SEGGER directly about the optimization of this function. With respect to general ways of optimizing from the i.MX RT perspective, I can think of executing from internal SRAM locations, and compiling with -O2 or -O3 compiler optimization levels.

BR,
Edwin.

[lsrbigfoot]

Thanks @EdwinHz!

So, I stumbled upon a function under emwin_support.c called 'emWin_memcpy'.

void *emWin_memcpy(void *pDst, const void *pSrc, long size)
{
  return memcpy(pDst, pSrc, size);
}

From the looks of it this call seems like a means of replacing memcpy() with alternative function calls. However, emWin_memcpy does not appear to be called during runtime.
How can emWin library be re-configured to call emWin_memcpy() during runtime?

[lsrbigfoot]

After reviewing thread, Imxrt1064 slow performance with Emwin - NXP Community I was able to figure out a way to implement a custom Frame buffer call (with and without DMA techniques). However, the change did not appear to make a difference in performance (i.e., just as good if not much worse). And yes, I was executing code from ITCM SRAM.

What really appeared to help was moving from Manual Multi-Buffering usage to Multi-Buffering usage that is automatically called by the Windows Manager which appears to depending on the result of GUI_Exec() call (i.e., more on-demand). [emWin Multi-Buffering - SEGGER Wiki]