: In looking very closely at your TFT picture, it seems that the : "outline" is actually the anti-aliasing pixels, drawn in the wrong : colors. Since you're running the fblin24 driver, it must be : that the RGB colors are in the reversed order, BGR, or : vice versa in the blend code. : : I don't have access to the source directly, but I think you : need to edit fblin24.c::linear24_drawarea_alphacol, and : reverse the R and B order in the core blending. IIRC : there are two source variables psr and psb, which : should be swapped (since the destination writes need to : stay in the same order.
In looking at the source for this, the blending IS being done in the proper order. It also looks fine on my system, running 24bpp. I suggest you move to Freetype v2.3.9, as I'm running. Also, we need to make SURE you're running the fblin24 subdriver, and linear24_alphacol is being called for the text output. I did notice a bug where the b/g/r was written in the wrong order, but this was only when usebg was true (it isn't in our sample app), and alpha = 0 (meaning background only should be drawn. So other than FT v2.3.9 mismatch, I'm not sure of the problem, unless you're not really running the 24bpp subdriver. : : If this works, it means that the order of the alpha-channel : RGB is opposite what I thought it was. Give it a try and : let me know. And thanks for looking closely at the output, : shows I probably need stronger glasses! LOL!! The alpha channel in this case is only 8bpp, so there couldn't be a mismatch in the rgb, as the alpha is just passed as 0-255, and then blended with the destination fg and bg colors. Regards, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
