nanogui: Thread: Solid background under variable-width fonts


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Solid background under variable-width fonts
From: Jim Ham ####@####.####
Date: 20 May 2010 15:18:44 -0000
Message-Id: <4BF5B54E.7000704@porcine.com>

Hi,

I have several text fields that are updated on screen a couple of times 
a second. I find that the freetype font FreeSans.ttf doesn't paint the 
background except just a few pixels surrounding each character. This 
leaves artifacts of previous messages on the screen.

My questions are can I force GrText to paint the background solid? Do I 
have to use GrFillRect() before painting the text? Do other fonts do 
this differently? Is there a better way?

Regards,

Jim Ham
Subject: Re: [nanogui] Solid background under variable-width fonts
From: "Greg Haerr" ####@####.####
Date: 20 May 2010 16:41:36 -0000
Message-Id: <03dc01caf83b$1fccb9f0$6564a8c0@winXP>

: I have several text fields that are updated on screen a couple of times 
: a second. I find that the freetype font FreeSans.ttf doesn't paint the 
: background except just a few pixels surrounding each character. This 
: leaves artifacts of previous messages on the screen.

By default, most text drawing is done drawing the foreground
bits only, using anti-aliasing if specified, blending the edges of
the characters with the existing background.

To turn on background pixel drawing using the current background
color, use GrSetGCUseBackground(gc, TRUE);

I have been working extensively with some issues in the
recent git repository.  The issues have to do with drawing
rotated character strings and some driver bugs.  I've recently
updated the drivers to make sure they always draw the
background bits when requested.  However, there are
still issues, as the freetype driver only draws character
glyphs (foreground and background) in a minimal bounding
box for the character, not the entire large string rectangle.

Jim, go ahead and try setting the above background drawing
request.  If there are still issues, I have some code that will
work, that I've not checked in (I'm in the middle of a
large update to all font subdrivers, where all use very
fast blit routines to output text, instead of pixel by pixel
as in the case with some font subdrivers).  I have decided
to wait until after 0.92 ships before integrating the
new design.


: 
: My questions are can I force GrText to paint the background solid? Do I 
: have to use GrFillRect() before painting the text?

The fixes I have talked about above use fillrect to fill the entire
area before drawing, so it shouldn't be necessary to do it on
your own.  The font subdriver also knows exactly where to paint
this rectangle.

:  Do other fonts do  this differently?

Each font subdriver (freetype2, freetype1, pcf, fnt and t1lib) do
this differently in the current code.  Also, the output routines
differ depending on whether anti-aliasing is specified. (antialiasing
is only supported in freetype and t1lib/type1 fonts).


: Is there a better way?

No, using GrSetGCUseBackground is the preferred approach.  Let
me know how it works.

Regards,

Greg

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.