Thinking about this a little more, I think there is no way of avoiding the client-side global: The thing is, once python is on the c-side, it might think the python state object (for which a pointer is kept on the c-side) has gone out of scope and so get rid of it. Playing with python object reference count is an option, but that's effectively a client side global too.
To be honest, the 4 hooks, only render() and preset_slot() are useful.
It is more non-C friendly to do
Set_two_hooks(...just_two..., void *context)
And have the client side doing allocation etc, and freetype just passes the context pointer along, instead of what we have now, having allocation and de-allocation routines as hooks too.
I think I have a 4th thing to raise: not very clear about the life-cycle of rec_surface - I think there is a possibility of leaking them if preser_slot() is called with cached multiple times. (I sort of notice these non-pairing create()/destroy() as pycairo etc don't have explicit destroy() methods). There is an extra destroy() in render(), but there probably should be a destroy() just before create in preset_slot() too to clear the previous rec_surface() if one blindly creates()?
On Thursday, 29 June 2023 at 22:37:46 GMT+8, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:
Hi,
Having looked at the librsvg code recently I thought I'll see if I could re-write it in python, with freetype-py / pycairo and gobject introspection of librsvg. Here it is.
https://github.com/rougier/freetype-py/pull/174
There is currently a small flaw I hope to fix in another commit soon: it is a bit painful to allocate a python object/dictionary to keep the state of the rendererhook, and pass it back and forth to c-side of libfreetype, so it is currently a client side global.
...