[sldev] A question regarding GL texture mapping in LLFontGL

[Alissa Sabre]

I have a question.

In function LLFontGL::render in a viewer source llrender/llfontgl.cpp,
there is a misterious code.  On around line 820-830, there are codes
to show a character glyph bitmap on the screen by drawing a rectangle
(GL_QUAD) with the character glyph bitmap as a texture.

What I don't understand is the purpose of PAD_AMT.

In the code, the source bitmap and the target screen are carefully
pixel aligned (i.e., the coverage of a single texel of the texture and
the coverage of a single fragment on the window are exactly matched.)
So, I think drawing a rectangle that has an exact size as the glyph is
enough.  However, the LL written code draws slightly large rectangle.

A magic constant PAD_AMT is 0.5f, and the code draws a rectangle with
0.5 pixels larger in all four edges.  Texture coordinates are also
enlarged 0.5 texels in a same way...  The actual texture is prepared
as one pixel larger in four edges for the purpose, and that margin
pixels are filled with a full transparency (alpha = 0.0).

The min and max texture filters are set to GL_NEAREST, so there are no
mixture of colors from surrounding texels,

Well, I see this code has nothing bad.  It works totally fine.  But,
why?  Why we need to do this?  I modified the code so taht PAD_AMT to
be 0.0, rebuild the viewer, and run it.  I saw no difference at all.

Two possible reasons came to my mind:

One possibility is a workaround for a broken GL implementation (bad
texture unit.)  There might be a broken GL that mistakenly
interpolates nearby texels or samples texture bitmap at a wrong
position, and LL dev tried to eliminate garbages on that particular
graphic card.

Another possibility is that the code is a historic remnant.  In
LLFontGL::render, I see several commented-out codes that tried
subpixel alignment of the character glyph images.  I can imagine that
in an older versions, LLFontGL::render tried to draw rectangles at non
integral coordinates, using some interpolation (probably GL_LINEAR).

Of course, I may be wrong and the real purpose of PAD_AMT is totally
different.

Should we keep it?  May I remove it?  Comments?

    Alissa Sabre


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/