glDrawPixels wackiness

[kanet77]

Hello, and welcome to my post. Make yourself at home.

If you have some experience using glDrawPixels() I'd like to hear from you.

I'm using glDrawPixels() to display a bitmap (actually two because I'm in stereo mode). I'm supporting pan and zoom operations on the image. I need to control the positioning of the drawn image down to the screen pixel. This means that I sometimes need to start drawing in the middle of an image pixel. However, glDrawPixels doesn't support this functionality, so instead I "shift" the whole image by starting to draw outside the window.

At first I couldn't start drawing outside the left or the bottom of the window. I used a trick with glBitmap() I found online to allow me to draw from outside the window. ( http://www.frii.com/~martz/oglfaq/clipping.htm -- Question 10.070) But it appears that I can't draw to the entire window if I do this. For example, if I start drawing from x = -10 (10 pixels outside the left window edge), the 10 rightmost pixels of the window will not be drawn to. This is exactly the same problem that occurs when the window is dragged off the left or bottom edge of the screen. So I guess this glBitmap() trick ensures that something is drawn rather than drawing nothing due to an invalid raster position. But if I can't draw to the entire window I really don't see the point.

I'm currently trying to get around this problem by using glDrawPixels() to draw the image in sections. I suppose this is a workable solution although it involves more calculations and I'm concerned about the inefficiency of calling glDrawPixels() four times. Especially when I draw the "column" on the right edge of the screen because these pixels are not in contiguous memory.

Has anyone had a similar problem? Thanks for any input.

-tom

[acerb]

Hi,

Thanks for home... ^^

Anyway, from my own experience, I think you'd better use QUADS and texturing. And if your pics are too large (only reason I'd see you to think using glDrawPixels - I didn't say it's a good one =P) then think to cut it in 4 QUADS and use Sub...
This way you won't have your glDrawPixel clipping problem anymore (as it's managed within the texturing engine) and it will likely be better for the performance too ^^ (I used to draw a scientific RMI pic' using glDrawPixels and it was way slower than now using textures)

Hope it helps

acerb

[This message has been edited by acerb (edited 03-25-2003).]

[kanet77]

Originally posted by acerb:
...if your pics are too large (only reason I'd see you to think using glDrawPixels - I didn't say it's a good one =P) then think to cut it in 4 QUADS and use Sub...


Yeah, I'm starting to think that large images isn't necessarily a good reason to use glDrawPixels. I've seen a lot of advice on this forum and others to use textured QUADS instead.

So do you mean cutting the image into 4 QUADS? Why is this necessary? Is that just to keep each texture at a manageable size? And when you say 'Sub' I assume you mean glTexSubImage2D ?

I think I'll give it a shot. Unfortunately I have little experience with textures so I'm sure this is going to be painful http://www.opengl.org/discussion_boards/ubb/tongue.gif .

Thanks for the advice, acerb.

I'll let you know how it works out.

-tom

[This message has been edited by kanet77 (edited 03-25-2003).]

[acerb]

Hi,

Happy it helps a little ^^

Yeah I was talking about glTexSubImage2D! You should use it for comptability if your textures are very large (ok until 1024*1024 from my experience) or if you have to often refresh only part of your image...

And don't worry about it, it's even more simple and effective than glDrawPixels, it's not painful (anyway, if you have troubles, just post, I'll answer if I'm not too far and if I'm able to =P)

Good luck

acerb

[kanet77]

The video card I'm using is the only one in the office with stereo capabilities. But if I can draw one image correctly then I can draw the other one.

I tried my program out on a couple other computers and it looks like my problem is just a limitation of the video card I'm using. We're planning to get a new video card and hopefully that will fix the problem. If nothing else, we should be able to use the glWindowPos* extension, which will make life easier and take away the need to use the glBitmap hack.

My program is just a prototype. The finished product needs a video card with more RAM and higher refresh rate anyway.

Thanks for the help.

Cheers,
-tom

[Gavin]

We do the same in stereo, but have to use textures as we draw on top and drawpixels is just too slow. Our card goes up to 2048 and no images we use get to this size. But you will find, if you need to, that interactively moving the images about the screen, for disparity etc, is much quicker with textures, also things like glscale and so on work nicely. Although I must admit we have a bit of a headache with getting the texture to represent the image properly, as in colour depth/quality of the image can be a bit backward. If you don't get this let me know!