RTGUI images

[Rob D'Entremont]

Hi,

 

I am currently displaying a bitmap on the LCD and having issues with performance.

 

The benchmark demo is a bit misleading as it simply fills rectangles with a single colour. This uses only native drawing functions and only converts the pixel format once per row, even this could be eliminated. So the frame rates reported by this demo are best case. In my case it reports 30 - 40 fps.

 

It's a different story entirely when displaying a bitmap with every pixel being converted between colour spaces (RGB888 -> RGB565P). Displaying an 800 x 480 bitmap was taking 326ms, barely 3 fps. After improving the colour space conversion routines and streamlining the pixel copying process I managed to get it down to 197ms, still only 5 fps and unacceptable.

 

What I plan to do now is simply buffer the converted image so that it can be blitted to the screen DC eliminating the visible drawing of the image. I realise there will still be the same 197ms delay while the image is converted but this can be done in advance. At first I thought the dc_buffer could be used for this purpose but then I noticed that it's frame buffer is fixed at 32bpp. I want a DC that uses the same frame buffer format as the LCD, in my case 565P. I have several full screen background images to display. As they are background images they are static with no transparency. I could render each to it's own DC and then each image could be displayed by simply copying the frame buffer from the buffered DC to the screen DC.

 

Any ideas before I start creating another buffered DC? Did I miss something? Or perhaps I could modify the existing dc_buffer to be more flexible? A function like rtgui_dc_buffer_create_compatible could take a DC as an argument and create a DC with the same properties.

 

Rob

 

[Grissiom]

Hi Rob,

On Wed, Jul 10, 2013 at 1:34 AM, Rob D'Entremont <rd...@iinet.net.au> wrote:

Hi,

 

I am currently displaying a bitmap on the LCD and having issues with performance.

 

The benchmark demo is a bit misleading as it simply fills rectangles with a single colour. This uses only native drawing functions and only converts the pixel format once per row, even this could be eliminated. So the frame rates reported by this demo are best case. In my case it reports 30 - 40 fps.

 

It's a different story entirely when displaying a bitmap with every pixel being converted between colour spaces (RGB888 -> RGB565P). Displaying an 800 x 480 bitmap was taking 326ms, barely 3 fps. After improving the colour space conversion routines and streamlining the pixel copying process I managed to get it down to 197ms, still only 5 fps and unacceptable.

 

What I plan to do now is simply buffer the converted image so that it can be blitted to the screen DC eliminating the visible drawing of the image. I realise there will still be the same 197ms delay while the image is converted but this can be done in advance. At first I thought the dc_buffer could be used for this purpose but then I noticed that it's frame buffer is fixed at 32bpp. I want a DC that uses the same frame buffer format as the LCD, in my case 565P. I have several full screen background images to display. As they are background images they are static with no transparency. I could render each to it's own DC and then each image could be displayed by simply copying the frame buffer from the buffered DC to the screen DC.

It's a good news that your image is just background image and it won't change on the fly. For such a scenario, it's better to convert the image to "HDC" file in advance. The converter is here:

http://www.rt-thread.org/phpBB3/download/file.php?id=380

The post thread is here(in Chinese):

http://www.rt-thread.org/phpBB3/viewtopic.php?t=407

You can save the hdc file to a system or a array on the flash. There won't be color translation when the image is displayed.

-- 
Good Luck,
Grissiom

[Rob D'Entremont]

Hi Grissom,

 

Thanks for the reply.

 

I wondered about image_hdc and where the image files came from. If I follow the link you provided it tells me I dont have permission, and I can't find the link in the post using the other link you provided. Could it be made available from one of the other sites such as code.google?

 

Using image_hdc also has it's problems. The hdc image appears to be a raw bitmap, therefore the file size would be 768000 bytes for 800 x 480 x 16bpp. This would use 768K flash, 768K RAM and a further 768K RAM since the pixel data is copied again, although this could be eliminated. Images must be converted at compile time, which is okay for my current situation but it would not be an option for use with images loaded from an SD card, or downloaded. A new set of images would need to be created and maintained to support any additional display formats.

 

The method I was proposing could load the image from a png (or any other format) file, in my case this file is only 98K. This would decompress to 1.5M but then this memory could be freed after the image was converted to the display format. Therefore using only 98K flash, 98K RAM, 1.5M RAM (temporary) and 768K RAM for the final image. A total of 964K per image and a temporary 1.5M buffer, compared to 2.3M per image. Images could be loaded at runtime or precompiled as part of the binary image. The same set of images could be used on multiple display formats.

 

I guess it is a tradeoff between memory usage vs flexibility + on the fly conversion.

 

I will look more at image_hdc and hopefully I will be able to download the converter, but I am still considering creating a buffered dc or modifying dc_buffer.

 

Regards,

Rob