[sldev] A question regarding GL texture mapping in LLFontGL
Alissa Sabre
alissa_sabre at yahoo.co.jp
Wed Oct 22 03:20:45 PDT 2008
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/
More information about the SLDev
mailing list