Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibilities for memory optimization in rendering outline #38

Open
nisargjhaveri opened this issue Jul 17, 2024 · 0 comments
Open

Possibilities for memory optimization in rendering outline #38

nisargjhaveri opened this issue Jul 17, 2024 · 0 comments

Comments

@nisargjhaveri
Copy link

I'm trying to get the outline rendering part from here to run on a microcontroller, and realized I don't have enough RAM to comfortably run this. Here is my version https://github.com/nisargjhaveri/esphome-advance-fonts/blob/main/components/advance_font/schrift.c

The fact that we need two double for each cell takes a lot of memory depending on the font and glyph height/width. I did change it float, which halves it as expected. Is there anything else we can do?

I was thinking about a couple of ideas, but I'm new to the space, and wanted to discuss if they make sense?

  1. Use int16 instead of float in Point. Use a scale factor let say 64 for points, so that it takes 6 bits for the current decimal part, and rest for the location. Would this give enough precision?
  2. Use int16 or int8 for Cell as well, with some scale factor.
  3. I see that most of the Cell are generally 0 when it reaches post processing. Can we instead use a hashmap so that we don't have to allocate the entire buffer for each pixel?

Anything else that we can do? How can we optimized further if we know the display is going to black or white. As in 1 bit per pixel. How can we optimize some of the rendering code for that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant