nanogui: Screenshot of FreeType2 2.3.5
Subject:
Re: [nanogui] Screenshot of FreeType2 2.3.5
From:
"Greg Haerr" ####@####.####
Date:
30 Apr 2010 21:47:31 -0000
Message-Id: <011c01cae8ae$b91560e0$6564a8c0@winXP>
: 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
