[ft-devel] Determining Upper Bound of memory consumption for a system using FT cache subsystem
Dear FreeType Developers, I have a few questions regarding freetype memory consumption upper bound; I am using Freetyper version 2.3.7 (1) static array: currently we know that all memory consumption by freetype is done through malloc calls and its variants. However, is there any other memory used in freetype, such as global arrays, which are used for memory allocation? If so, do they need any kind of configuration? (2) Is there a way for determining the upper bound of memory usage for freetype when cache is being used. I know that we can set the upper bound for cache nodes (glyph image, cmap, sbitchace, etc.), but is there a way to determine the memory consumption for FT_FACE and FT_SIZE? From what I have seen regarding this, we can only limit the number of FT_FACE and FT_SIZE; however, how to determine the memory requirements for a given number of allowable FT_FACE and FT_SIZE. I am using freetype for an embedded system at the moment, thus, memory is really a constraint, and it's very important for me to be able to determine the size of the heap. best regards Maggy Anastasia Suryanto ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?
On 03/05/2010 02:26 AM, mpsuz...@hiroshima-u.ac.jp wrote: Checking the source code, I wonder if I should also check for (face_flags FT_FACE_FLAG_EXTERNAL_STREAM) to detect whether it's an mmapped stream or the user provided it (and hence we cannot mprotect). The docs say: Don't read or test this flag. Please let me know more detail about what the information is needed at the part. Yet I'm not understanding the idea of blob in HarfBuzz. Well, in short, all the hb_blob_t in HarfBuzz is about communicating to harfbuzz what it can do with the memory backing the font file. There are three different cases we are interested in: - The memory is read-only; harfbuzz will make a copy if it needs to modify it. - The memory is writable and it is ok to write to it. harfbuzz will not make a copy. - The memory is read-only, but can be made writable using mprotect() or similar (win32, ...) functionality. HarfBuzz only makes changes to the font data if it detects corrupt fonts. The changes are NOT meant to be written back to the font file. Currently the hb-ft glue layer assumes that font data is mmap()ed or are otherwise mprotect()able. This fails for examples when: - Font data is in ROM. In this case mprotect() will fail and harfbuzz will make a copy of the memory. Not a huge problem. - FreeType malloc()ed the font data. In this case, mprotect() is not necessary and will probably affect memory beyond the font data (since mprotect works on whole pages). - Font data is coming from the user. In this case it may not be desirable to modify the data. Adding API to FTStream to be able to detect the above cases, specially the user-provided data, would be useful. Thanks, behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [FYI] Re: Getting pathname from FT_Face (patch for future discussion)
Attached (get-stream-info.diff) is a revised patch with a feature to get the info about the origin of the memory in FT_Stream object, which is inspired by recent discussion with Behdad about mprotect() to the buffer in FT_Stream object. Sample code (get-stream-info.c) invokes the new APIs FT_Get_MemInfo_From_Stream() and FT_Get_Path_From_Stream() then shows results, aslike: $ ./get-stream-info.exe /usr/X11R7/lib/X11/fonts/100dpi/helvR24.pcf.gz memory allocator=[gzip-buff] pathname=[/usr/X11R7/lib/X11/fonts/100dpi/helvR24.pcf.gz] Just a proof of concept. Regards, mpsuzuki get-stream-info.diff.lzma Description: Binary data get-stream-info.c.lzma Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
