This could be VERY useful that OpenGL support hardware BitBlt and all this stuff, because glCopyPixel() and other functions are too slow and i can see many messages on the boards deal with “how can i do fast blitting ?”.

Many vdo cards can do this nowadays. It’s really simple a very fast, and even DirectDraw drivers manage to use it instead of software blitting. So why not OpenGL ? That could be great don’t you think ?

I think what V-man was trying to say is that its not OpenGL, its that your video card has to support optimal usage in their OpenGL drivers. If they wanted to they could optimize many diffrent areas of OpenGL to allow for fast blits, like say detecting if a rectangle has the same width and height as the texture map and then using the fastest operation they can by just blitting it. DirectDraw does the same thing, when I was first learning DirectDraw a long time ago I accidently was sending the wrong size rectangle to it, causing it to slightly scale the image by one pixel, I knew there was something wrong because performance was terrible (my guess was that it was reverting to software blits when I accidently stretched the image), if the driver developers wanted to they could do the same thing in opengl and detect the optimal kind of raster operation to use, if your video card does not support this then maybe you should ask them to, OpenGL has a frame work for it.

Yes, i understand. But what i wanted to say is that OpenGL should provide fonctions better than glReadPixel() or glCopyPixel() for 2d blitting, and why not with the use of hardware blitting if the video card can make it.
Antoche

Well, maybe you should not use functions like glReadPixel or glCopyPixel, try using glBegin with one of primitive types, again if your video card drivers are built for performance they should be able to tell if you are passing an orthogonal rectangle the same dimensions as the texture and use the most optimal hardware/software blit routines for it.