Re: [ft] Memory management and stream I/O question (Freetype v1 --> v2)

[Alex Taylor]

On Sat, 23 Mar 2013 06:26:28 +0100 (CET) Werner LEMBERG wrote:

> > When you say "does the right thing", does then FreeType actually
> > close the streams after returning the requested data?
> 
> I don't think so, but if you tell me what functions you have to call,
> I can look it up more closely.
> 
> >    Note #2: On exit of each function reading from font file the API
> >    TT_Flush_Stream() must be called.
> 
> This is very vague.  Can you give an example?

It is...  I didn't write it myself but I think I understand the general 
meaning.

This DLL plugs in to the OS shell as a kind of module using OS/2's 
"intelligent font interface" (IFI) driver architecture.  Applications which 
want to access fonts make their request to the shell, which in turn calls 
this driver.  

Let's say an application requests information about a font which is 
installed on the system.   It queries the OS/2 graphics engine, which in 
turn queries the responsible IFI driver (our DLL).

Our DLL opens the font, retrieves the mandated information and populates a 
special font metrics structure (which uses a lot of information from the 
font's OS/2 table), and that in turn gets passed back to the application, 
with a few modifications, as: 
http://www.edm2.com/index.php/OS2_API:DataType:FONTMETRICS 

However, if our DLL doesn't close the font's actual file handle before 
returning, it stays open.  The file handle is owned by the process that 
called the DLL (either the application or the OS/2 graphics engine server, 
not 100% clear which)... but the process has no access to (or knowlege of) 
that file handle because it's managed internally by FreeType within our 
DLL.  Since applications (and the desktop shell itself) are constantly 
querying font information, the system would run out of file handles very 
quickly.  The font files themselves would also be locked open, unable to be 
uninstalled or whatever.

In FreeType v2, the correct way of closing the stream seems to be with 
FT_Done_Face().  But that destroys the associated face data (metrics and so 
on) as well.  This is obviously suboptimal; in the existing DLL (using 
FreeType v1) we keep the X most recently-used face objects in a cache so we 
don't have to keep re-querying their information.  (Some of these APIs may 
get called with high frequency in a very short timespan.)  Just the file 
handle itself is closed.

Therefore, it's important not only to be able to close the stream handle 
without destroying the face object, I also have to be able to re-open the 
stream on demand and start using the face object again.


> > Now, I imagine I could grab the face->stream handle and close it
> > myself.  In FT1, the library automatically re-opened the stream if
> > necessary.  However, I'm not sure (looking through the FT2 code)
> > that this is still the case.  I suppose I could add my own wrapper
> > functions to do this, but I wanted to know if there was a better
> > way.
> 
> Wrapping the code sounds just fine.

I'll examine the best ways of doing this.  I haven't dug that far into the 
internals of how FT_Face manages the stream yet; I'll probably have other 
questions soon, though. :)


> > I can of course provide the custom files (how?); I'm just noting
> > that they are highly specialized.
> 
> Well, if your custom files are not useful to normal FreeType clients
> (this is, ordinary OS/2 applications) I believe it is better that the
> code gets directly included with the OS/2 font driver.

I've written the ftsystem part to fit into the usual abstract framework, 
anyway.  That part might be useful to people who want to write other 
FreeType-based OS/2 presentation drivers (for instance, a system printer 
driver).  It's a bit premature at the moment, though, since I haven't 
properly run the code through its paces yet.  :)


> If you need FreeType fixes to non-custom files please tell us so that
> we can add the needed functionality.

Noted, thanks.

-- 
Alex Taylor <address@hidden>
http://www.altsan.org