> > 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. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
