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
<[email protected]> 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.
...
