Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

glDrawPixels and performance

147 views
Skip to first unread message

Stewart Carroll

unread,
Dec 31, 1996, 3:00:00 AM12/31/96
to

Hi all,

Sorry if this question has been posed numerous times before, but here
it goes anyway. I am generating a scan-line image within the
framebuffer using the following code:

void Image::DrawRaster(int current_raster)
{
unsigned char *pp = Pixels + ((current_raster-1) * (xresolution*3));
glRasterPos2f(0, current_raster-1);
glDrawPixels(xresolution, 1, GL_RGB, GL_UNSIGNED_BYTE, pp);
}

The image looks fine, however when I expose the window I have a callback
function which repaints the window. It is here that I run into the
problem of performance. My expose event calls the following function:

void ImagE::Paste()
{
unsigned char *pp;

glRasterPos2i(0, 0);
glDrawPixels(xresolution, yresolution, GL_RGB, GL_UNSIGNED_BYTE,
Pixels);

}

I guess my question is how can I improve the performance of the callback
function so that my refresh time improves(I am using default settings
for glPixelStore, glPixelTransfer and glPixelMap). I would like the
performance of this opengl code to be the same as I had within GL. When
using GL the refresh time was such that the user could not tell that the
window was repainting the pixmap when an expose event occurred.

Stewart Carroll
scar...@ptc.com

Nate Tuck

unread,
Dec 31, 1996, 3:00:00 AM12/31/96
to

In article <32C937...@ptc.com>, Stewart Carroll <scar...@ptc.com> wrote:
> glDrawPixels(xresolution, yresolution, GL_RGB, GL_UNSIGNED_BYTE,
>Pixels);

If you are using an Extreme or older machine, the answer probably lies in
GL_ABGR_EXT. I would be surprised if this wasn't in the FAQ by now.

nate


Allen Akin

unread,
Dec 31, 1996, 3:00:00 AM12/31/96
to

In article <5abl9n$j...@fido.asd.sgi.com>,

Nate Tuck <na...@blit.engr.sgi.com> wrote:
|
| If you are using an Extreme or older machine, the answer probably lies in
| GL_ABGR_EXT. I would be surprised if this wasn't in the FAQ by now.

Yes. Since we're talking about SGI machines, here's the version in the
SGI FAQ:


SGI graphics Frequently Asked Questions (FAQ)
-65- Why is OpenGL's glDrawPixels slower than IrisGL's lrectwrite?
Date: 28 Jul 1995 00:00:01 EST

Allen Akin of SGI (ak...@tuolumne.asd.sgi.com) says: It's not, for the
most common cases. After all, similar microcode and the same hardware
are used for both commands. However, there are three issues to keep
in mind.

First, some midrange and low-end SGI graphics adaptors (particularly
XS, XZ, Elan, and Extreme) transfer ABGR-ordered images much faster
than they transfer RGBA-ordered images. The normal image format in
IrisGL was ABGR, while in OpenGL it's RGBA. So to achieve the same
performance in OpenGL that you did in IrisGL on those machines, you
need to use ABGR-format images in OpenGL. The ABGR extension
available in Irix 5.3 and later releases allows you to do this. See
``man glintro'' for background information on using OpenGL extensions,
and ``man gldrawpixels'' for details on ABGR. Note that
RealityEngine, IMPACT, and all future machines will process RGBA data
at least as fast as ABGR, so RGBA is the way to go for new code.

Second, some OpenGL pixel data types are faster than others. For most
machines, unsigned byte RGBA (or ABGR) is the fastest full-color type.
Unsigned byte and unsigned short are usually the fastest gray-scale
types. Signed integer types are slower.

Third, OpenGL pixel operations have a much richer set of features than
IrisGL, and if any of those features are enabled, then image transfer
can be significantly slower. Always disable the features that you
don't need. The following code fragment disables features that are
likely to make glDrawPixels slow:

/*
* Disable stuff that's likely to slow down glDrawPixels.
* (Omit as much of this as possible, when you know in advance
* that the OpenGL state will already be set correctly.)
*/
glDisable(GL_ALPHA_TEST);
glDisable(GL_BLEND);
glDisable(GL_DEPTH_TEST);
glDisable(GL_DITHER);
glDisable(GL_FOG);
glDisable(GL_LIGHTING);
glDisable(GL_LOGIC_OP);
glDisable(GL_STENCIL_TEST);
glDisable(GL_TEXTURE_1D);
glDisable(GL_TEXTURE_2D);
glPixelTransferi(GL_MAP_COLOR, GL_FALSE);
glPixelTransferi(GL_RED_SCALE, 1);
glPixelTransferi(GL_RED_BIAS, 0);
glPixelTransferi(GL_GREEN_SCALE, 1);
glPixelTransferi(GL_GREEN_BIAS, 0);
glPixelTransferi(GL_BLUE_SCALE, 1);
glPixelTransferi(GL_BLUE_BIAS, 0);
glPixelTransferi(GL_ALPHA_SCALE, 1);
glPixelTransferi(GL_ALPHA_BIAS, 0);

/*
* Disable extensions that could slow down glDrawPixels.
* (Actually, you should check for the presence of the proper
* extension before making these calls. I've omitted that
* code for simplicity.)
*/

#ifdef GL_EXT_convolution
glDisable(GL_CONVOLUTION_1D_EXT);
glDisable(GL_CONVOLUTION_2D_EXT);
glDisable(GL_SEPARABLE_2D_EXT);
#endif

#ifdef GL_EXT_histogram
glDisable(GL_HISTOGRAM_EXT);
glDisable(GL_MINMAX_EXT);
#endif

#ifdef GL_EXT_texture3D
glDisable(GL_TEXTURE_3D_EXT);
#endif

Ian Reid

unread,
Jan 3, 1997, 3:00:00 AM1/3/97
to Stewart Carroll

I was also experiencing some performance problems with glDrawPixels,
which were fixed by creating a direct rendering context :

Widget w;
GLXContext context;
XVisualInfo * vi;
Arg args [ 1 ];
XtSetArg ( args [ 0 ], GLwNvisualInfo, &vi );
XtGetValues ( w, args, 1);

context = glXCreateContext ( XtDisplay ( w ), vi, 0, GL_TRUE);
^^^^^^^
Good Luck

--
Ian Reid, Tel : 510-649-9711
Tippett Studios, Fax : 510-649-9399
2741 Tenth Street, Voicemail : 236
Berkeley CA 94710

0 new messages