nanogui: Thread: Screenshot of FreeType2 2.3.5

This is how Freetype2 2.3.5 looks like on avr32 (big endian), modeline:

mode "640x480-48"
    # D: 23.333 MHz, H: 26.042 kHz, V: 48.405 Hz
    geometry 640 480 640 480 24
    timings 42857 96 96 34 8 64 16
    rgba 8/0,8/8,8/16,0/0
endmode

Only white on black and black on white seems to render correctly. Am I
doing something wrong?

Compiling with SCREEN_PIXTYPE = MWPF_TRUECOLOR0888.

Regards
Daniel

: Only white on black and black on white seems to render correctly. Am I
: doing something wrong?

Again, make sure you're running the git code, as many changes have
been made recently with anti aliased drawing. (These use the
drawarea_alphacol entry point, versus drawarea_msb_first for
no-anti aliasing).

Of course, you'll also make sure you have the MWFT_ANTIALIAS
flag set using GrSetFontAttr().

: 
: Compiling with SCREEN_PIXTYPE = MWPF_TRUECOLOR0888.

Actually, this only sets the MWPIXELVAL typedef.  The
actual framebuffer drawing subdriver that is used depends on 
the specific fb geometry.  From your posted results, you're
running the fblin24.c driver (which implements alpha blending
for freetype 2 using alpha col)

BTW, if you send me the source to your demo program,
I'll add it as a test program to our tree :)

The latest git code is also pushed as microwindows-src-snapshot.tar.gz
on the website.

Regards,

Greg

2010/4/29 Greg Haerr ####@####.####
> : Only white on black and black on white seems to render correctly. Am I
> : doing something wrong?
>
> Again, make sure you're running the git code, as many changes have
> been made recently with anti aliased drawing. (These use the
> drawarea_alphacol entry point, versus drawarea_msb_first for
> no-anti aliasing).

I do run latest Git code. I actually pulled a few hours ago, right
before taking those screenshots. :-)

> Of course, you'll also make sure you have the MWFT_ANTIALIAS
> flag set using GrSetFontAttr().

That, I do.

> : Compiling with SCREEN_PIXTYPE = MWPF_TRUECOLOR0888.
>
> Actually, this only sets the MWPIXELVAL typedef.  The
> actual framebuffer drawing subdriver that is used depends on
> the specific fb geometry.  From your posted results, you're
> running the fblin24.c driver (which implements alpha blending
> for freetype 2 using alpha col)

Thanks for pointing out the underlaying nature!

> BTW, if you send me the source to your demo program,
> I'll add it as a test program to our tree :)

Well, it's just a five minute hack. Watch the crappy uncleand
copy-and-paste code at Gist:
http://gist.github.com/383732


Any further ideas how to make Freetype2 working? Has it got to do with
the big endian target? If I just get a point to start debug, I'll do
that tomorrow. Now it's time to go home. :-)

Regards
Daniel

: Well, it's just a five minute hack. Watch the crappy uncleand
: copy-and-paste code at Gist:
: http://gist.github.com/383732
: 
: 
: Any further ideas how to make Freetype2 working? Has it got to do with
: the big endian target? If I just get a point to start debug, I'll do
: that tomorrow. Now it's time to go home. :-)

I'll grab your test program and look at the results over here,
and send you comments.

For a starting point, checkpoint the linear24_drawarea_alphacol
routine, that's the entry point that should be called from 
the freetype driver (GdDrawAreaInternal).  FT2 creates an
8bpp alpha channel for the glyph, which is then combined
using drawarea_alphacol with the foreground color.

Regards,

Greg

: mode "640x480-48"
:    # D: 23.333 MHz, H: 26.042 kHz, V: 48.405 Hz
:    geometry 640 480 640 480 24
:    timings 42857 96 96 34 8 64 16
:    rgba 8/0,8/8,8/16,0/0
: endmode
: 
: Only white on black and black on white seems to render correctly. Am I
: doing something wrong?
: 
: Compiling with SCREEN_PIXTYPE = MWPF_TRUECOLOR0888.

Daniel - 

I tested this with your program, changing the font to
arial.ttf (I don't have your DejaVu font), and things
work fine, the alpha blending is correct.

In looking at the fblin24.c driver, I noticed the problem,
I wasn't combining the destination properly during
the alpha blend.  Try the new fblin24 (or the new
tree in git), I think things should work properly now.

Regards,

Greg

2010/4/30 Greg Haerr ####@####.####
> : mode "640x480-48"
> :    # D: 23.333 MHz, H: 26.042 kHz, V: 48.405 Hz
> :    geometry 640 480 640 480 24
> :    timings 42857 96 96 34 8 64 16
> :    rgba 8/0,8/8,8/16,0/0
> : endmode
> :
> : Only white on black and black on white seems to render correctly. Am I
> : doing something wrong?
> :
> : Compiling with SCREEN_PIXTYPE = MWPF_TRUECOLOR0888.
>
> Daniel -
>
> I tested this with your program, changing the font to
> arial.ttf (I don't have your DejaVu font), and things
> work fine, the alpha blending is correct.
>
> In looking at the fblin24.c driver, I noticed the problem,
> I wasn't combining the destination properly during
> the alpha blend.  Try the new fblin24 (or the new
> tree in git), I think things should work properly now.

It's alot better, but still outlined in under certain circumstances.
It looks alot better on the screenshot, but the artifact is more clear
on my tft screen so I've attached a photo[1] of it too (now using arial
font).

Regards
Daniel

[1] Photo too big for attachment. See http://yfrog.com/j4imag0020bdj instead.

> It's alot better, but still outlined in under certain circumstances.
It looks alot better on the screenshot, but the artifact is more clear
on my tft screen so I've attached a photo of it too (now using arial
font).

Daniel - 

Oh, the fun and wonderfulness of writing and rewriting six
bit-twiddling drivers all at once!! LOL

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.

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!!

Regards,

Greg

: 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

2010/4/30 Greg Haerr ####@####.####
> : 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.

Running nano-X compiled with DEBUG = Y it begins with:
 "640x480x24bpp linelen 1920 type 0 visual 2 colors 16777216 pixtype 4"

This should be the fblin24.c right?

> 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.

But according to the screenshot the blending doesn't seem correct right?

Regards
Daniel

> Running nano-X compiled with DEBUG = Y it begins with:
> "640x480x24bpp linelen 1920 type 0 visual 2 colors 16777216 pixtype 4"

>This should be the fblin24.c right?

Yes, I think so.

> But according to the screenshot the blending doesn't seem correct right?

In thinking more about this, it's likely a big endian issue, since
I haven't been able to test that here.  Can you upgrade to freetype
2.3.9, so we're running the same code?

Also, you might check out my new bin/fbe framebuffer emulator,
you can run it in 24bpp mode on your desktop on X11,
try:

bin/fbe -c -d24

then modify drivers/scr_fb.c and set BPP to 24,
and then FRAMEBUFFER=/tmp/fb0; bin/nano-X ...

That will run nano-X with the emulator, and we can determine
whether it runs on your desktop properly or not.

Regards,

Greg