Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

SGI graphics Frequently Asked Questions (FAQ)
Section - -64- Why is OpenGL's glDrawPixels slower than IrisGL's lrectwrite?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Property taxes ]


Top Document: SGI graphics Frequently Asked Questions (FAQ)
Previous Document: -63- What is "/dev/tport" used for?
Next Document: -65- BUGS AND PROBLEMS
See reader questions & answers on this topic! - Help others by sharing your knowledge
Date: 28 Jul 1995 00:00:01 EST

  Allen Akin of SGI <akin@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

User Contributions:

Comment about this article, ask questions, or add new information about this topic:




Top Document: SGI graphics Frequently Asked Questions (FAQ)
Previous Document: -63- What is "/dev/tport" used for?
Next Document: -65- BUGS AND PROBLEMS

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
sgi-faq@viz.tamu.edu (The SGI FAQ group)





Last Update March 27 2014 @ 02:12 PM