freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks


From: Behdad Esfahbod
Subject: Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks
Date: Sun, 7 Jul 2019 12:50:12 -0700

I haven't read the entire thread carefully.  However I want to point out that how the SVG library allocates and frees memory is its own business and should NOT be tied to FreeType memory routines.

You still need to negotiate the bitmap allocation though.

On Sat, Jul 6, 2019 at 5:55 AM Moazin Khatri <address@hidden> wrote:
Hi everyone,

As Behdad adviced, I removed the rendering port's state from the global scope and instead decided to store it in `FT_LibraryRec'. The first thing I realized was that the state would be of a different type for each SVG rendering library, thus, it seemed pointless to add a new structure in `FT_LibraryRec'. Instead, I just added a new field `svg_renderer_state' which is a `void *'. Now every library could create their own structure and reference it inside `FT_LibraryRec'. However, for that to happen, memory needs to be allocated and freed by the port, which brought me back to the problem I discussed a day ago here. `ft_mem_*' cannot be accessed from outside FreeType if the client program is linking dynamically. 

To solve this issue, memory allocation needs to be performed from the FreeType side. Thus I added a new hook `get_state_size' which will be called to query the size of the `state' structure of a particular port. Then FreeType can allocate this memory and later free it too. I did the same thing for the image buffer. I created a new hook `get_buffer_size' which can be called to query the size needed to place the final rendered image. The rendering port uses this memory and it sets the `FT_GLYPH_OWN_BITMAP' flag, thus, FreeType can free it later.

This has fixed ALL of the memory leaks I was aware of. I have checked using the FreeType memory debugger as well as `valgrind'. The code works on all the fonts and test fonts I had and also works with FreeType demo tools.

Please have a look at my latest commit in FreeType repo and the last commit 4c86cca of my `resvg' port to take a look at these new changes. 

Let me know what you guys think about this solution (adding two new hooks to query the required memory and allocating it on FreeType side). I'm having mixed feelings about this! :D

Best,

Moazin


--
behdad
http://behdad.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]