What do you think about drawing with pixel-transfer functions (like glDrawPixels). Is it effective method of drawing? Would it be useful for things like backgrounds, menus or should I reather use textured primitives?
Thanks for your advice!
prefer textured primitives to DrawPixels(). the key difference is that a texture can be stored in video or agp memory for very fast access, whereas with something like DrawPixels(), you have to transfer the image to the card every time you draw, making it extremely slow.
you can test this out yourself. just make a program that draws an image covering a full screen window using DrawPixels(), and then make another program that draws a textured quad covering a full screen window. you’ll find that the latter method gives you much better frame rates.
Applications shouldn’t restrict themselves to specific resolutions. Pixel transfers (vs textured primitives) quickly maneuver you into tricky situations wrt resolution. You could try using glPixelZoom, of course, but that’s quite a shady corner of OpenGL (filtering or the absence of filtering has never been clearly worded in the spec for values of magnitude!=1).
If you’re mainly supporting NV/ATI cards, you can in fact replace most glDrawPixels calls with rectangle texture equivalents, where you get the added bonus of clearly defined and adjustable filtering rules.
Thanks for your help.
Your arguments convinced me to use primitives. But… what is the advanatage (or any use) of pixel transfer commands, then? Is it meaby a relict of old times?
Pixel transfers are in concept a good thing, and very versatile. Eg, primitive rendering does not (yet?) allow arbitrary stencil writes, glDrawPixels does.
You have the resolution thing. glPixelZoom really should have been fixed in the specification.
Then you will likely suffer the most ‘interesting’ implementation behaviour if you try different target formats, source formats and data types. The pixel path has been almost completely neglected by consumer hardware vendors, which is a shame IMHO, but that’s how it is.
The stencil writes I mentioned above are in practice utterly useless on most cards, because they just run too slow, the same applies to depth writes. We’re talking about low single digit fps, if all you do is write a 640x480 depth region.
Also, I’ve been trying to get good plain color transfer performance out of ATI for almost two years now, the best I can manage right now is 33 fps for 640x480 color writes on a Radeon 9500Pro … that’s 40MB/s or so.
NVIDIA cards are very strong in this test, my Geforce 3 is ten times as fast, but there are shady corners there as well.
To make a story that might very well be much longer a little shorter, consistent performance across different vendors is still a huge issue. The more interesting transfer modes don’t perform well at all, regardless of vendor. It’s a driver thing, but as long as the big guys don’t request better pixel path performance, this is going nowhere.
OTOH, you need to realize what glDrawPixels does differently from textured primitives. First, it by definition transfers rectangles, OTOH primitives can have arbitrary shapes and also easily allow image transformation (perspective, texture matrix, filters, etc).
Second, glDrawPixels is always ‘one shot’, as it pulls from user memory. So it’s best suited for things that are constantly updated. An image that’s going to be drawn unchanged over and over again shouldn’t be transferred this way, it should reside in graphics memory, and this is easiest with textures.
Well, this is again theory. In practice per frame texture updates and primitive drawing may very well even be faster than using straight glDrawPixels, though this is IMHO exactly the usage model that glDrawPixels was designed to handle. A shame.
Woow. 
Thanks