[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Feb 25 17:01:36 PST 2013


https://bugs.freedesktop.org/show_bug.cgi?id=61412

--- Comment #8 from James Ogden <rexhunter99 at gmail.com> ---
(In reply to comment #7)
> Can you elaborate on what you mean by this?  I believe that Eric's proposal
> was for you to change the way the application is rendering.  I'm not sure
> how this has any affect on end-users troubleshooting things.
Seriously I feel like I'm a canary, repeating the same tune over and over.
I can't rely on a texture based font stored in the game directory, or even the
truetype/freetype fonts (except maybe Ubuntu/fixed on Linux and Arial on
Windows) because I am catering for people who do weird stuff to their computers
and files go missing mysteriously.  So instead I rely on something I know is
there and if its not, then their system is completely buggered.

> I'm assuming that you have fonts stored on disk as bitmap (1-bit per pixel)
> images, and that's why you're mentioning filesystems.  You can use this data
> as a texture by using the GL_PIXEL_MAP_I_TO_A table.  The data is sent to
> glTexImage2D like:
> 
>     glTexImage2D(GL_TEXTURE_2D, 0, width, height, 0,
>                  GL_ALPHA4, GL_COLOR_INDEX, GL_BITMAP, pixels);
> 
> Configure the GL 1.2 texture combiners and blend mode to blend the font the
> way you want:
> 
>     glTexEnvi(GL_TEXTURE_2D, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>     glBlendFunc(GL_SRC_ALPHA, GL_ZERO);
>     glBlendEquation(GL_FUNC_ADD);
> 
> Then draw a single quad in the color you want the font to be:
> 
>     glColor3f(1.0f, 0.0f, 0.0f);
>     glBegin(GL_QUADS);  // or your favorite way to draw
>     glTexCoord2f(...);  // location of the character in the atlas
>     glVertex2f(...);
>     ...
>     glEnd();
> 
> You could even build those calls into display lists (as you currently do
> with the glBitmap calls) to keep the changes isolated from the reset of your
> code.
> 
> Excluding the call to glBlendEquation, that will work on every OpenGL
> implementation since GL 1.1, and it will probably be faster than glBitmap on
> every GL implementation since the data doesn't need to be re-uploaded for
> each drawing operation.
I know how to do all of this, again I do NOT have a font texture file, I rely
on system installed fonts because if they aren't there, then the system is
buggered to hell.

> Some implementations may cache the bitmap data in GPU memory with the
> display list, but there's no guarantee.
Yes I am aware of that, but this isn't an implementation specific thing, it's
Mesa specific on all intel renderers for Linux.

> We have a small team, and a lot of other things to work on.  The probably
> that we will have time to optimize this case is very, very small.  We have
> never encountered any other application that depends on the performance of
> glBitmap.
Hardly an excuse if you ask me, I have a two man team working on a big project
but we never make excuses like that, we simply prioritise any issues we
encounter and get to them when we can.

And this is probably why no one ports games over from Windows, because the Mesa
implementations are horrible, fantastic fast when you use Core 3.0 stuff and
2.1 stuff, but otherwise you'd never be able to port golden titles from the
1990's over without gutting their rendering systems and rewriting them yourself
by hand.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130226/8d2a4e75/attachment-0001.html>


More information about the mesa-dev mailing list