Re: some more issues with the new API

[Stefan Seefeld]

Just van Rossum wrote:

> [ thread-safe drivers ]
> >I have not all details in mind, but I believe it all related to the amount
> >of sharing between objects and drivers. Thread-safety meant either duplicate
> >most data or make the design more complex. And the first option wasn't really
> >welcome..
> 
> But of course data duplication is not an option... My point is that if you
> decouple all state from the face object, it wouldn't neccesarily result in
> a more complex (or less efficient) design, except you need to explicitly
> pass all state around. But maybe that's exactly what you don't like...

why would you ? Now you pass a face (pointer) to each glyph function. With an
external glyph type you'd pass that instead (which internally holds a reference
to face, so you still can access the face internal data).

To reiterate:

now you have

FT_Face face = ...// create face

FT_Load_Glyph(face, idx, flags); // load a glyph

FT_Bitmap bitmap;

FT_Get_Glyph_Bitmap(face, bitmap);

--------------

while I simply propose something which looks like

--------------

FT_Face face = ...// create face

FT_Glyph glyph = FT_Face_Load_Glyph(idx, flags); // load a glyph

FT_Bitmap bitmap;

FT_Get_Glyph_Bitmap(glyph, bitmap);

--------------

there is really not a single bit of data more in my version which
needs to be passed around. All I change is making Glyph a named
variable (in contrast to an anonymous hidden one).

To reiterate this as well: not a single bit of memory management
needs to be changed if the use case is the same. Use 'copy on write'
techniques to allocate a new glyph only if someone wants a new one
while the old buffer is still referenced.

Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: address@hidden

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...