Magic sequences of operations

OpenGL Development
#1

I was having a problem with a very short program that draws a bitmap and a pixel image.

For the bitmap, I would set the raster position, set the color, then draw the bitmap 3 times in a row, to get three light blue-green letter F’s in the lower left corner.

For the pixel image, I would draw it centered over the mouse location. If the pixel image is going over the edge of the bottom or left sides, some extra work is performed so that only the part that fits on the screen is copied, so the raster position is always on the screen.

I found that when the pixel image started to slide off the bottom or left side, when the extra steps are taken, the bitmap would appear in white, even if I picked a different color.

I also found that it didn’t matter if I executed the bitmap code before or after the pixel image code - the bitmap would still be white.

Note that nowhere in my code did I ever set the color to white.

I eventually discovered that by setting the bitmap color first, THEN setting the raster position and drawing it, the problem went away - the bitmap always appears in the desired color, regardless of what the pixel image is doing.

Is this something that occurs a lot in OpenGL - needing to find the correct magic sequence of operations?

Does this kind of thing depend on the video card, OpenGL driver, and/or operating system?

Is there any site with some general advice about what sort og gotchas to look out for?

I’m using OS X.

Tx.

#2

OpenGL is a state machine, so any state you set for previous operations persists. Equally, anything unset is pretty much undefined. If you don’t set a colour and you get weird colours then it’s your own fault. :stuck_out_tongue:

On a more practical note, this basically means you’ve got to remember to set appropriate state, and in general disable stuff after you’ve finished working with it (ie, always assume a single, well-known state and if you change it, change it back).

If you want a totally robust solution you’ll need a high-level renderer with drawing state encapsulated in rendering style objects / settings.

#3

In terms of returning to a well-known state, I take it that it is better to do this with glPushAttrib and glPopAttrib?

Would it be a significant performance hit to just always use glPushAttrib with GL_ALL_ATTRIB_BITS, just to make life easy?

Is there any real performance hit if, for example, you have 100 objects that all turn alpha blending on and off individually, rather than turning it on once at the beginning?

#4

Setting the state can be a very costly operation. It depends on the state and possibly the driver. I remember that texture attributes were very slow to set. Although it is always best to profile this yourself, I have to say that reducing state switches is always a porformance priority.

#5

I don’t tend to use pushAttrib, 'cos I have it all hidden inside rendering classes mostly (and 'cos I only use simple state most of the time). Generally though the only really expensive state changes are texture binds and vertex/fragment program binds.