Re: [ft-devel] color framework

[Alexei Podtelezhnikov]

> > 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?
FT_LOAD_COLOR | FT_LOAD_RENDER | FT_LOAD_TARGET_BGRA

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.