On Wed, Dec 19, 2018 at 10:35 AM Behdad Esfahbod <beh...@behdad.org> wrote: > > On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov <apodt...@gmail.com> > wrote: >> >> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov >> <apodt...@gmail.com> wrote: >> > > Alexei, I think we miscommunicate. >> > >> > I struggle to get your attention to FT_Glyph_To_Bitmap. >> >> I just discovered that, while ignoring the FT_Glyph abstraction in the >> current implementation, we also disregard FreeType caching system, see >> FTC_ImageCache_Lookup. This is just lovely but please continue your >> arguments against fire-walling FT_Render_Glyph from accessing FT_Face. > > > I don't understand what you mean; if you're being sarcastic or not. But > FreeType caching system does not solve any problem for the systems I know. > It's at best useful only for small clients for single-threaded use.
If I suggested removing FT_Glyph and FreeType caching, that would be sarcastic. I just demonstrating how poorly the current implementation is thought out. It is a hack, nowhere near an integrated solution. I am also offering a path forward by implementing a dedicated BGRA renderer which would accept merged outlines tagged with color and/or layer index. We can discuss how to call the renderer without any references to FT_Face. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel