[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] FTC_Manager - crashing on 'FTC_Manager_Done'
From: |
David Turner |
Subject: |
Re: [Devel] FTC_Manager - crashing on 'FTC_Manager_Done' |
Date: |
Tue, 05 Dec 2000 16:32:33 +0100 |
>
> 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