touchgfx::RenderingBuffer class

@class RenderingBuffer RenderingBuffer.hpp touchgfx/canvas_widget_renderer/RenderingBuffer.hpp Rendering buffer wrapper. Rendering buffer wrapper. This class does not know anything about memory organizations, all it does it keeps an array of pointers to each pixel row. The general rules of rendering are as follows. 1. Allocate or create somehow a rendering buffer itself. Since the library does not depend on any particular platform or architecture it was decided that it's your responsibility to create and destroy rendering buffers properly. You can use any available mechanism to create it - you can use a system API function, simple memory allocation, or even statically defined array. You also should know the memory organization (or possible variants) in your system. For example, there's an R,G,B or B,G,R organizations with one byte per component (three bytes per pixel) is used very often. So, if you intend to use class render_bgr24, for example, you should allocate at least width*height*3 bytes of memory. 2. Create a RenderingBuffer object and then call method attach(). It requires a pointer to the buffer itself, width and height of the buffer in pixels, and the length of the row in bytes. All these values must properly correspond to the memory organization. The argument stride is used because in reality the row length in bytes does not obligatory correspond with the width of the image in pixels, i.e. it cannot be simply calculated as width_in_pixels * bytes_per_pixel. For example, it must be aligned to 4 bytes in Windows bitmaps. Method attach() can be called more than once. The execution time of it is very little, still it allocates memory of heigh * sizeof(char*) bytes and has a loop while (height--) {...}, so it's unreasonable to call it every time before drawing any single pixel :-) 3. Create an object (or a number of objects) of a rendering class, such as renderer_bgr24_solid, renderer_bgr24_image and so on. These classes require a pointer to the RenderingBuffer object, but they do not perform any considerable operations except storing this pointer. So, rendering objects can be created on demand almost any time. These objects know about concrete memory organization (this knowledge is hard coded), so actually, the memory you allocated or created in clause 1 should actually be in correspondence to the needs of the rendering class. 4. Render your image using rendering classes, for example, Rasterizer 5. Display the result, or store it, or whatever. It's also your responsibility and depends on the platform.