Big stack allocations

[ivmarkov]

The library has "no dynamic allocations" but that's at the expense of large structures allocated on the stack. E.g. here and here. (I'm not even sure how the latter one works under ESP-IDF with its default stack size of ~3K for the main thread.)

Further, the HAGL_CHAR_BUFFER_SIZE calculation might have a bug as you are dividing the DISPLAY_DEPTH by 2, while I believe it should be by 8?

[pwolny]

This issue caused me problems also. A larger program on Raspberry Pico hanged with "isr_hardfault" very randomly. After limiting HAGL_CHAR_BUFFER_SIZE the problem went away and I can even use larger fonts now.

[oclyke]

Chiming in - one solution to this problem would be to allow an alternative form of these API calls which allow the user to provide their own working area or other information. I also think this concept could play nicely with the idea of passing in the surface to API calls. (e.g. #48 (comment) and #43 (comment)) In this case the surface could become a structure of options including the intended output target as well as possibly additional memory for speeding up large operations.

[tuupola]

There are several operation which needs work memory. These include things like loading a jpg, outputting a char and outputting a hline. I have been pondering if they should should use shared memory.

I have also changed my mind about dynamic allocation. It is ok to do once on startup. It is still not ok to do everytime some function is called. For example here:

https://github.com/tuupola/hagl_pico_mipi/blob/master/hagl_hal_double.c#L129-L134