search

tuupola / hagl

Hardware Agnostic Graphics Library for embedded
https://www.appelsiini.net/tags/hagl/
MIT License
296 stars 47 forks source link

Big stack allocations #44

Closed ivmarkov closed 1 year ago

ivmarkov commented 3 years ago

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 commented 1 year ago

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 commented 1 year ago

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. https://github.com/tuupola/hagl/pull/48#issuecomment-907184635 and https://github.com/tuupola/hagl/issues/43#issuecomment-907198420) 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 commented 1 year ago

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