[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] color framework

From: Alexei Podtelezhnikov
Subject: Re: [ft-devel] color framework
Date: Tue, 18 Dec 2018 08:30:34 -0500

> > FT_LOAD_COLOR used to be a loading flag only.
> This depends on what you exactly mean with `loading' and
> `rendering'...

Naturally, the rendering is FT_Render_Glyph, which takes render_mode.
Because FT_Glyph's are rendered with dummy FT_Face, we cannot and must
not use FT_LOAD_COLOR or even use FT_Face there. This is a critical
point even from threading perspective: the rendering is so slow that
we should not hang FT_Face waiting. We have to agree on this.

> > The choice is between a hack and a proper implementation.
> We need both, as I've tried to implement in `master': FT_LOAD_COLOR
> should trigger a standard case with some default blending; for finer
> color and blending control separate functions should be provided to
> allow direct layer access.

Which is these flags is spurious?

I am ok with assuming FT_LOAD_TAGET_BGRA if FT_LOAD_COLOR is set.
FT_LOAD_RENDER should be explicit! It is absolutely  crazy to enforce
slow rendering unless explicitly asked for. FT_LOAD_COLOR should just
merge all outlines/layers/contours and tag them with COLOR, of course.
I am just warning. FT_LOAD_COLOR does not imply FT_LOAD_RENDER yet.
Keep it this way.

Do we need the iterator once the layer outlines are merged and tagged
with color? I do not see any purpose, frankly.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]