[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetype-devel
Subject:    Re: [ft-devel] color framework
From:       Alexei Podtelezhnikov <apodtele () gmail ! com>
Date:       2018-12-19 16:00:57
Message-ID: CAJU=AjVeF-q_BO__REkn_h7V-CQABL8PNn7MZsxfmUPHQAO6AA () mail ! gmail ! com
[Download RAW message or body]

On Wed, Dec 19, 2018 at 10:35 AM Behdad Esfahbod <behdad@behdad.org> wrote:
> 
> On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov <apodtele@gmail.com> wrote:
> > 
> > On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
> > <apodtele@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


[prev in list] [next in list] [prev in thread] [next in thread]