[Low prio] Offscreen drawing in a bitmap

[ivmarkov]

Given that HAGL is essentially a software rasterizer (with an option to delegate a few things to the HAL below), I'm a bit surprised that bitmap_t is missing all the draw* and fill* methods that you've done for the "main" HAGL surface. The only difference between the bitmap variants and the regular ones is that in the bitmap variants you need a bitmap version of hagl_get_pixel and hagl_put_pixel. Which would be good to have anyway.

Treating bitmap_t as a valid offscreen drawing surface might allow you to fold back into the main HAGL project the "double" and "triple" buffering complexity, which (IMO) would reduce the complexity of the "driver" code.

[tuupola]

Do you mean that all primitive drawing functions should require a context where to draw? For example instead of:

 hagl_put_pixel(x0, y0, color);

one should provide the bitmap_t to draw to:

 hagl_put_pixel(bitmap, x0, y0, color);

[ivmarkov]

That might be one option - the introduction of the notion of an abstract 'drawing surface' is often what e.g. other toolkits do. Some of these even differentiate between a 'surface' (where you render) vs 'context' (= surface + any state like current colors and font).

A completely different approach is implemented here, where the 2D primitives (line, circle, rectangle, text, etc.) are viewed as top-level objects which render themselves by producing an iterator over a range of points. Might be particularly useful for the embedded space indeed.

The other, 'backward compatibility' option would be to just introduce a bunch of bitmap_* functions. At the expense of less abstraction in the API, i.e. you cannot abstract higher-level rendering functions over what surface they render. Your call, I guess...

[tuupola]

The more I think of it including a pointer to surface or context in the function calls would solve many problems. I remember I originally decided against it because I thought would make the function calls unnecessary complex. Live and learn...