[ft-devel] Questions regarding memory consumption related to FT's glyph
From:
Maggy Anastasia
Subject:
[ft-devel] Questions regarding memory consumption related to FT's glyph image cache lookups
Date:
Wed, 10 Mar 2010 17:06:27 +0800
Hello,
I have a question regarding the upper bound of cache nodes (glyph image, cmap and sbit nodes) of FreeType Cache manager. I am currently using FreeType 2.3.7.
From the API reference, FTC_Manager_New() allows us to determine the following:
Maximum number of active FT_Face; and Maximum number of active FT_Size; and Maximum number of bytes of glyphs (& cmap & sbit) nodes in a cache manager at one time;
From the above description, I inferred the correctness of the following two statements:
1. All memory usage related to glyph & cmap & sbits allocation in cache are bounded. 2. Given the first statement is true, we can decide the maximum memory usage for cache activities if we know the size of FT_Face and FT_Size objects that are going to be used in a system.
However, after running several experiments, it seems to me that the first inferred statement I made is not necessarily true.
Part of the experiments I did was calling FTC_ImageCache_LookupScaler() several times to obtain different glyphs from the same face and the same size. I use FT_LOAD_FORCE_AUTOHINT|FT_LOAD_RENDER flag as the input of the call.
The table below summarizes the results I got from using FreeMono.ttf, width = 40 pixel, height = 40 pixel: - the first column are actions which I think are happening for each call to FTC_ImageCache_LookupScaler()
- the second column lists the values for curr_weight update of the cache manager I am using (from FTC_ManagerRec_) for the action of each row - the third column is the number of bytes allocated for the action of each row
- fourth column is the difference between 2nd and 3rd column, and is the amount of unaccounted memory being allocated for the action of each row
face & size creation | | | load glyph T + |480 |13864 |13384
load glyph S |492 |1980 |1488
load glyph R |568 |880 |312 load glyph Q |644 |644 |0 load glyph P |480 |480 |0 load glyph O |564 |564 |0
load glyph N |568 |568 |0 load glyph M |590 |878 |288 load glyph L |502 |502 |0 load glyph K |546 |546 |0 load glyph J |544 |544 |0
load glyph I |414 |414 |0 load glyph H |524 |524 |0 load glyph G |564 |564 |0 load glyph F |502 |502 |0 load glyph E |502 |790 |288
load glyph D |524 |524 |0
Other than adding new glyph image node, The first call of FTC_ImageCache_LookupScaler() (to load character 'T') will also trigger the creation of FT_Size and FT_Face objects too. Thus, the unaccounted memory in the "bytes- update" column for the first call may be caused by the FT_face and FT_size cache object creation.
On the contrary, I think, subsequent calls will only add new glyph nodes to the cache (and no Face or Size node since we are passing the same scaler object for all calls). Cache manager always updates its curr_weight for each addition (or replacement) of glyph nodes to the cache. This curr_weight is limited by the max_weight, which is set by FTC_Manager_New().
Different from my expectation, there are some unaccounted bytes being allocated in addition to the one tracked by Cache manager's curr_weight attribute. (e.g. glyph S, R, M and E in the above examples). I have repeated the above experiment using different fonts and different sizes. I found that the unaccounted bytes occur for different glyphs irregularly accross different fonts.
Is there any explanation of the additional bytes allocated other than the ones tracked by cache_manager's curr_weight? Can we know the maximum bound of the values? I need to know these to be able to determine the overall memory consumption upper bound of freetype. Many thanks in advance. Your help is very much appreciated.