Re: [Devel] FTC_Manager - crashing on 'FTC_Manager_Done'

[David Turner]

> 
> I notice (via the wonders of viewCVS) that the fix has a line
> manager->sizes_lru;
> (somewhere around line 300), I assume you meant
> manager->sizes_lru = 0;
> 
> :-)
> 
Oops, and now I understand why I shouldn't be working on two
projects at the same time ;-) thanks..

> Also, wouldn't the same problem occur in FTC_Manager_New in the
> Error: handler, where just about the same block of code is executed?
> 
Technically speaking, the caches are both empty, which means that
ftc_manager_done_face is never called in the error handler of
FTC_Manager_New. But it sure doesn't hurt to reset them in the
correct order :-)


On a slightly related topic, I'm currently experimenting with
several alternative implementations for the abstract glyph cache
class (i.e. FTC_Glyph_Cache), and I'd welcome comments on the
subject.

Basically, the current implementation implements a two-level hashing:

  - all glyph nodes belonging to the same FaceID+font size+image format
    are grouped in something called a "glyph set"

  - each glyph set contains a _static_ hash table (using 64 buckets
    by default, for now, though 128 or higher would be good choices)

  - each cache object contains a (small) LRU cache of glyph sets

  - when a glyph node is looked-up, the corresponding glyph set is
    taken from the cache object (or a new one is created if needed),
    then the glyph is searched in the set's hash table

  - the implementation also ensures that frequently used glyph sets
    and nodes are searched as quick as possible (basically by moving
    the last searched set and glyph node to the top of their respective
    lru and bucket lists)

it's not especially advanced or optimal, but it works pretty well,
especially for Latin text where a few glyphs per font are used most
of the time in typical text.

I am now experimenting with the following ideas, please let me know
if you have comments on them:

  - dynamic hash tables are nice and flexible, but each re-sizing operation
    needs a complete re-computation of the hash value for all of the table's
    nodes. This _is_ a problem when you have a slow processor with lots of
    cached nodes, because it will somewhat "stall" your application..

  - using a one-level hashing scheme, by embedding glyph set information
    within the cache node themselves. Using a static or dynamic hash table
    would also mean

  - using trees. This seems to be much more reasonable, because the cost
    of re-ordering the structure is paid on each insertion/removal, instead
    of a one big stop as in the case of dynamic hash tables, however, I'm
    unsure they'll perform better than hash tables for fast lookups (my
    past experience tells me that they're usually slightly slower than
    hashes in numerous occasions, so testing is needed).

Voila, any comments :-) ?

Regards, 

- David