Bitmap draw seems slow

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

  • Bitmap draw seems slow

    Hi, I am using a 24bpp display on a LPC4357 with emWin.
    I am using GUIC_888 color conversion and GUIDRV_LIN_32 display driver, the CPU speed is set at 204MHz, the bitmaps are cached in the internal flash memory.
    I am very satisfied with all of the features, but it seems that the bitmap drawing gets a little slow.
    I am checking the timing on a dialog with an ICONVIEW widget with 4 x 72x72 icons, 2 text widgets and four buttons without images, the background is a colour without gradients.
    I tried both RGB 24bpp bitmaps and 32bpp bitmaps with little difference, the refresh time of the whole screen seem around 400ms, with about 100ms to redraw a single 72x72 bitmap.
    Does the GUIDRV_LIN_32 use the full 32 bit bus of the LPC4357 when doing the graphic operations?
    Are there any suggestions to achieve a better performance ?
    • as stated I tried both 24BPP and 32BPP bitmaps with no appreciable difference
    • I have tried both with and without RTOS with no difference
    • I have checked the timing with an oscilloscope on a general purpose I/O which is set at the very beginning of the call of the GUI_Exec and reset after the same call
    • I have tied using a custom copy buffer routines with no difference
  • Hi Adrian, many thanks for your kind reply.
    yesterday and today I further dug into the problem.
    It seems there are two main reasons for the slow display refresh:
    • I am using the GUIDRV_Lin32 and the memory devices, in effect disabling memory devices boosts the performances, as correctly stated in your manual
    • handling the transparency eats a lot of CPU time, and this is stated in your manual too, so OK
    • if I disable the transparency handling I can obtain a complete refresh of the display in about 300ms, with 3 icons 72x72 24bit RGB, 4 buttons with text and two long text antialiased 4bpp on my display, so this is good
    • if you disable the multiple buffers, you can appreciate the operations done by the windows manager, and really you can appreciate that the screen painting is a little bit slow when copying a bitmap on the background
    • is there any way to further improve the bitmap draw? It seems to me that when drawing a bitmap 24bit RGB, the performances should be very similar to the solid colour, stated that no colour conversion is needed, but instead there is about 400ms lost to refresh the whole 480x272 display with a bitmap @204MHz CPU clock/102MHz SDRAM
    • many thanks again!
  • Hello,

    I would recommend you to perform drawing operations from within the WM_PAINT event, only. Also invalidating windows should be done only in case the appearance would change. Please try avoid full screen updates as much as possible.

    Best regards,
    Adrian
  • Hi Adrian,
    thanks for your reply!
    • about the WM_PAINT: in effect I am just using only widgets, so I suppose the paint operations are already optimized and handled by the windows manager.

    I would ask you again: Is there any way to accelerate the framebuffer paint when using a bitmap as the background?

    I ask you this again because we noticed that when I fill the background with a solid colour, the fill is really fast; but when I use a bitmap set with the native colour, i.e. no colour conversion is needed, the paint is anyway a bit slower.

    Many thanks again for your help!