[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 16:22:29 PST 2013


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

--- Comment #7 from Ian Romanick <idr at freedesktop.org> ---
(In reply to comment #4)
> (In reply to comment #3)
> > Please, please, please don't use display lists, and don't use bitmaps. 
> > Display lists are basically nvidia-only for performance, so it's a bad route
> > to go.  Use normal texturing and "discard" instructions to render your
> > bitmaps, or normal texturing and alhpa blending if you're doing fixed
> > function.  Sticking your textures in one big atlas and vertex data in a vbo,
> > you'll get way better performance than you'd ever get out of bitmap.
> 
> Really dude, did you not read anything I said?  It's a compatibility thing,
> plus the people who play this game are mostly either kids or computer
> illiterates so if a font texture goes bye bye because of something silly
> they did, I'll be the one who has to personally troubleshoot their issue. I

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.

> *want* to use the proper method, but I've had that many issues in the past
> with relying on users being intelligent enough to keep track of their file
> system that I now know better.  I know they're slow, I know they're
> deprecated and I do care, but I don't have much choice if I want to stay
> sane.

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.

Some implementations may cache the bitmap data in GPU memory with the display
list, but there's no guarantee.

> Oh and my last machine was an AMD ATi setup, dual radeon graphics, display
> lists worked fine using the official drivers, or 3rd party ones, I just hate
> APUs which is why I upgraded as soon as the laptop died before the warranty
> ran out. So this isn't a case of nvidia drivers being better than the rest.

(In reply to comment #6)
> (In reply to comment #5)
> > I did read it.  But alpha blended texturing would also do the job that
> > glBitmap does, and is just fine with fixed function GL.
> You clearly DID NOT read it:
> 
> > The people who play this game are mostly either kids or computer illiterates
> > so if a font texture goes bye bye because of something silly they did, I'll
> > be the one who has to personally troubleshoot their issue. I *want* to use
> > the proper method, but I've had that many issues in the past with relying on
> > users being intelligent enough to keep track of their file system that I now
> > know better.  I know they're slow, I know they're deprecated and I do care,
> > but I don't have much choice if I want to stay sane.
> 
> Besides, I have reported a clearly broken feature of the driver, which
> appears to be related to glBitmap, perhaps instead of solely glCallLists,
> and it should be fixed. So stop telling me what I should do instead of using
> it when I've given my perfectly reasonable reasons and am not interested in
> people such as yourself arrogantly parading around like you do.  Either help
> with fixing the issue that is the driver seemingly falling back to some slow
> software implementation or bugger off.

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.

-- 
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/8b7e2a02/attachment.html>


More information about the mesa-dev mailing list