[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some more issues with the new API
From: |
Just van Rossum |
Subject: |
Re: some more issues with the new API |
Date: |
Wed, 15 Mar 2000 21:11:54 +0100 |
At 1:49 PM -0500 15-03-2000, Stefan Seefeld wrote:
>I'v a couple of other issues with FT2 which are mostly
>naming and type conventions. One is the following:
>
>FT_Library is defined as a FT_LibraryRec_ *, yet
>function take a pointer to a Library as argument,
>thus you end up with a double indirection. Why is
>FT_Library a pointer ?
That's only true for FT_Init_FreeType, in which case it is a return value.
All other functions take a plain FT_Library.
>To make another point clear from one of my last mails:
>
>with your glyph slot approach, you loose thread safety.
>You can't dereference the current glyph safely since it
>can at any time get invalidated through a parallel call
>to Load_Glyph in a different thread. I propose you decouple
>glyphs from their faces in that faces still act as a
>glyph factory, but they don't return a pointer to an
>internal static object, rather they return a heap allocated
>object which the caller of Load_Glyph is to delete once he
>is done.
After exchanging a couple of emails with Stefan, I finally understood his
point, and it is very good one indeed. Thread safety is one issue, a clean
OO API the another. To illustrate the latter point: the FT_GlyphSlot
face->glyph field is destroyed upon FT_Done_Face(), but this means I need
to hold on to the face object as long as I have a reference to the glyph
slot. With automatic object deallocation (as is needed for a Python
wrapper, and is highly desirable for a C++ wrapper) this is problematic. So
decoupling FT_GlyphSlot (which could then be renamed FT_Glyph) from
FT_Face, as Stefan suggests, seems a good move. These are some consequences
of this change (off the top of my head):
- the FT_Face->glyph field disappears.
- the FT_Glyph object no longer needs to be a linked list
- FT_Glyph objects need to always be explicitly destroyed in C
- FT_Get_Glyph_Bitmap() becomes a method of FT_Glyph: FT_Glyph_Get_Bitmap()
- the FT_Glyph object needs a reference to a memory handler
Basically this questions much of the FT2 architecture, so it would be a
major change. Still, I think it's important to go to the bottom of this,
since the better the C API is *now*, the longer it'll remain useful (ie.
the longer we can postpone FT3 ;-).
Just
- some more issues with the new API, Stefan Seefeld, 2000/03/15
- Re: some more issues with the new API,
Just van Rossum <=
- Re: some more issues with the new API, Just van Rossum, 2000/03/15
- Re: some more issues with the new API, Stefan Seefeld, 2000/03/15
- Re: some more issues with the new API, Just van Rossum, 2000/03/15
- Re: some more issues with the new API, Stefan Seefeld, 2000/03/15
- Re: some more issues with the new API, Just van Rossum, 2000/03/15
- Re: some more issues with the new API, Stefan Seefeld, 2000/03/15
- Re: some more issues with the new API, Just van Rossum, 2000/03/16
- Re: some more issues with the new API, David Turner, 2000/03/16
- Re: some more issues with the new API, Just van Rossum, 2000/03/16
- Re: some more issues with the new API, David Turner, 2000/03/16