RTGUI

[Rob D'Entremont]

In general RT-Thread has worked well from the very first compile. There have been a few little issues and I needed to write the peripheral drivers which I expected. Some of the existing drivers were also rewritten for better performance and thread safety. Despite the lack of English documentation I have had a relatively pleasant experience working with RT-Thread.

RTGUI on the other hand, not a very pleasant experience at all. When it comes to a graphical interface performance is critical. RTGUI has many performance issues, not to mention bugs and unfinished code.

As I mentioned earlier blitting an 800x480 bitmap to the screen was taking over 320ms. With a little effort I have managed to optimize the code so that it now takes 180ms. The color transformation function is called for every pixel being blitted to the screen. You would think there would be some effort to make this function as efficient as possible. Nope! None what so ever! Even the blit function itself performed poorly.

Attempting to use the the dc_buffer to help improve the situation was also a total failure. Blitting from dc_buffer to dc_hw also requires a color transformation for each pixel. The code in image_hdc seems to be an attempt to address this problem, although I can't understand why. It only works for preprocessed images, the utility for which I wasn't able to download. So I wrote yet another dc buffer. One with an internal pixel format that matches the hardware. All color transformations are done while buffering. Blitting to the hardware dc is fast using memcpy. Blitting a 800x480 image to the display now takes 17ms.

A device context cannot be queried for any of it's properties. The parent dc only contains the dc type and a pointer to the engine, but the structures for the other dcs are all private to their module. Why? It would certainly be handy to be able to get a dc's pixel format, or size, or even it's frame buffer.

Creating an image from memory should be a function of the image engine and not a generic function in image.c that simply redirects filerw. The image engine could then perform more optimal reading of the data in memory.

Speaking of filerw, it too is broken. The function mem_read returns the number of blocks read while stdio_read returns the total bytes. So the return value from rtgui_filerw_read has a different meaning for memory reads than it does for file reads.

Because of this all the calls to rtgui_filerw_read in image_bmp fail when reading from memory as the return value is not what is expected. The parameters in those calls are in the wrong order. Other code that uses filerw works mostly because the return value is not even checked. Obviously no code review, no testing!

Image_png doesn't support transparency, since the dc engine does not provide a means to read the existing pixel back from the frame buffer. I have had to extend the dc engine to provide this function in order to support transparency. The existing code also used floating point to compose the semi-transparent colors. How optimal is that! The code was clearly a copy and paste from a website with no effort to optimize.

Rotating and scaling a bitmap is currently only supported for bitmaps images. To rotate an area of a dc's frame buffer you first need to create a bitmap from it. One look at the code and I haven't even tried to use it. I have instead written a fast, generic function that can rotate and/or scale a bitmap in one step. By bitmap I don't mean the a bitmap image, you simply pass it pointers to source and destination frame buffers, source and destination rectangles, source and destination centers of rotation and the amount to rotate and/or scale.

Font support, if you can call it that, consists of two sizes of an English font, or you can use the Chinese font. The utility that was used to generate the fonts can't be found, or so I'm told. A GUI with almost no font support? Since this is unacceptable I've had to write my own font engine. I have also written a utility that generates a font image for any font that can displayed using Windows. I can now create a variety of fonts in a number of sizes including smooth or anti-aliased glyphs as well as bold and italic. The font engine also supports kerning as well as Unicode UTF-16 so displaying English, Russian and Chinese simultaneously is no problem. The rest of RTGUI now needs to be updated to also support Unicode. I also plan to extend the font engine so that referencing a font calls the font engine to allow it to do things such as deferred load on the first reference, etc. Referencing a font also needs to allow specifying other front properties such as bold, italic, etc. as well as font name and size.

These items represent most of the issues I have had to address in RTGUI but there have been others, such as some of the dc drawing routines etc. I would have liked to have been more productive in creating my graphical interface, but I have instead had to add or fix support in RTGUI to make it useable.