-
Notifications
You must be signed in to change notification settings - Fork 105
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
fix most freetype/harfbuzz related memory leaks #1618
fix most freetype/harfbuzz related memory leaks #1618
Conversation
There's still one small leak remaining due to using `FT_Done_Library` instead of `FT_Done_FreeType` to handle the Freetype's library lifecycle: its memory object is not freed on exit.
Btw, how much of that amount to the well known KOReader memory leaks (cf koreader/koreader#5998 (comment)) ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit over my head, so it must be ok :)
Good question, memory does increase as more features get used, menus opened, but I'm not sure it's leaking. Honestly, I don't have to restart on my Kindle anymore thanks to:
monolibtic is currently broken (because of the visibility patches), but technically fixable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not up to snuff on the ft/hb API, but this looks sound ;).
There's still one small leak remaining due to using
FT_Done_Library
instead ofFT_Done_FreeType
to handle the Freetype's library lifecycle: its memory object is not freed on exit.This is also the precursor to some memory optimizations.
This change is![Reviewable](https://camo.githubusercontent.com/23b05f5fb48215c989e92cc44cf6512512d083132bd3daf689867c8d9d386888/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)