Newbie Q: glDrawPixels vs texture-mapping onto polygon
Kenny Tilton
I found some sample code which used gluBuild2DMipmaps and glDrawPixels
and got that working OK for displaying the images flat.
But then I wanted to map the texture onto a 3D shape. I took NeHe Lesson
6 as my starting point, and finally got that working when I backed off
my gluBuild2Mipmaps and went with the glTexImage2D from the Nehe code.
Then to see if I could still just draw the pixels to the screen, I added
a call to glDrawPixels to display the pixel data associated with the
texture (I kept both around) directly to a rectangle elsewhere on the
screen.
That worked, but it was mad slow.
A little googling revealed a message from this NG in which someone
provided a long list of features to turn off in order to speed up
gldrawPixels, and that worked.
But I had already worked out that I could just map the texture to a
polygon perpendicular to the viewing angle and get what looked like the
same effect.
So I am wondering if I should just use texture-mapping for everything.
Or does glDrawPixels offer more flexibility? I suppose the answer might
lie in that one is drawing to the framebuffer under the control of the
raster pos, so I do not have to worry about rotations etc.
My immediate objective is to use a big JPG as the background for a
window which will contain 3d buttons, the 3D effect achieved via opengl
lighting of 3d polygon models. I want the background image to continue
intact across the buttons (distorted on the sides). So I am thinking I
need to map corresponding bits of the underlying window texture onto
each face of the button (except the back).
Since I am just buiding a typical window with buttons, sliders, et al, I
will not be doing anything like rotating or scaling or even moving
things much, so I /could/ use glDrawPixels for the overall
background...but a small voice is telling me I should be consistent and
have even the background be yet another big polygon. Otherwise I am
mixing opengl modalities to achieve one outcome (the window with one
skin stretching across different components) and that way lies madness.
I think I just figured it out writing this. :)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Antonio Bleile
> I have been playing around with displaying JPGs and BMPs via opengl.
>
> I found some sample code which used gluBuild2DMipmaps and glDrawPixels
> and got that working OK for displaying the images flat.
>
> But then I wanted to map the texture onto a 3D shape. I took NeHe Lesson
> 6 as my starting point, and finally got that working when I backed off
> my gluBuild2Mipmaps and went with the glTexImage2D from the Nehe code.
>
> Then to see if I could still just draw the pixels to the screen, I added
> a call to glDrawPixels to display the pixel data associated with the
> texture (I kept both around) directly to a rectangle elsewhere on the
> screen.
>
> That worked, but it was mad slow.
>
> A little googling revealed a message from this NG in which someone
> provided a long list of features to turn off in order to speed up
> gldrawPixels, and that worked.
>
> But I had already worked out that I could just map the texture to a
> polygon perpendicular to the viewing angle and get what looked like the
> same effect.
One big advantage of glDrawPixels is that you can use arbitrary
widths and heights of your image (for lazy programmers...). Textures
unfortunately still need power of 2 sizes (in most OGL implementations).
> [...]
>
> I think I just figured it out writing this. :)
>
> kenny
>
You missed one important issue: glDrawPixels takes the image
data from main memory and is thus pretty slow. A texture (once
it is loaded) in could reside in main memory too (when it is swapped
out, or if you're on an O2 it's always in memory, or with mesa...),
but in most cases it's stored in texture memory of your
graphics board, where it can be accessed very quickly.
If you want to draw your background just once use glDrawPixels,
if you use the same image very often use a texture.
Try to bench the performance of both methods and you should
see a significant difference...
Regards,
Toni
--
for mail, mirror: ed.lausivksa@elielb
Kenny Tilton
Antonio Bleile wrote:
> Kenny Tilton wrote:
> One big advantage of glDrawPixels is that you can use arbitrary
> widths and heights of your image (for lazy programmers...). Textures
> unfortunately still need power of 2 sizes (in most OGL implementations).
Doh! So that is why (until now) I could not get anything other than a
select few BMPs (sized to powers of 2 (by someone else!) to work as a
texture) to work as textures. God forbid I should read the blue book
when something does not work. (I try to learn by stealing working code,
but that flopped when I switched to images not supplied with the code.)
Thx, you just saved me much hair-pulling.
> You missed one important issue: glDrawPixels takes the image
> data from main memory and is thus pretty slow. A texture (once
> it is loaded) in could reside in main memory too (when it is swapped
> out, or if you're on an O2 it's always in memory, or with mesa...),
> but in most cases it's stored in texture memory of your
> graphics board, where it can be accessed very quickly.
Gotcha. But about this swapping out business: is that something I have
to worry about (ie, I would have to call glTexImage2D again) or are the
opengl internals handling that? I am guessing the latter or the doc
would say something on that (and ogl programming would be even harder <g>).
>
> If you want to draw your background just once use glDrawPixels,
> if you use the same image very often use a texture.
At this "crawl before you walk" stage I am redrawing the whole scene on
each (GLUT) redisplay call. The above is encouraging in that it sounds
as if I can use some scheme (off-screen buffer?) which allows
incremental redraws of just things which have changed. But I am getting
fine performance so far, so I'll hold off on that a while.
Thx again for a /ton/ of help.
fungus
>
> One big advantage of glDrawPixels is that you can use arbitrary
> widths and heights of your image (for lazy programmers...). Textures
> unfortunately still need power of 2 sizes (in most OGL implementations).
>
Not true. You don´t have to use every pixel in a texture.
You can just use the lower w*h rectangles of a texture.
This wastes memory, but it works just fine. If you have
the texture_rectangle extension then you don't waste
the memory.
> You missed one important issue: glDrawPixels takes the image
> data from main memory and is thus pretty slow.
Make that "can be slow on PC consumer graphics cards".
There are plenty of systems where glDrawPixels is
lightning fast.
In fact, the very first PC graphics cards were fast,
it was NVIDIA who killed glDrawPixels with their TNT
cards.
--
<\___/> Real men don't use glu!
/ O O \
\_____/ FTB. For email, remove my socks.
Antonio Bleile
>[...]
>> You missed one important issue: glDrawPixels takes the image
>> data from main memory and is thus pretty slow. A texture (once
>> it is loaded) in could reside in main memory too (when it is swapped
>> out, or if you're on an O2 it's always in memory, or with mesa...),
>> but in most cases it's stored in texture memory of your
>> graphics board, where it can be accessed very quickly.
>
>
> Gotcha. But about this swapping out business: is that something I have
> to worry about (ie, I would have to call glTexImage2D again) or are the
> opengl internals handling that? I am guessing the latter or the doc
> would say something on that (and ogl programming would be even harder <g>).
>
You absolutely don't have to worry. OGL takes care of that.
For advanced control you might want to take a look on
glAreTexturesResident and glPrioritizeTextures, etc.
>>
>> If you want to draw your background just once use glDrawPixels,
>> if you use the same image very often use a texture.
>
>
> At this "crawl before you walk" stage I am redrawing the whole scene on
> each (GLUT) redisplay call. The above is encouraging in that it sounds
> as if I can use some scheme (off-screen buffer?) which allows
> incremental redraws of just things which have changed. But I am getting
> fine performance so far, so I'll hold off on that a while.
>
What? :-/
For simplicity I would draw the whole thing every time and
swap the buffers when you're done (are you familiar with
double buffering?).
> Thx again for a /ton/ of help.
>
You're welcome.
Antonio Bleile
> Antonio Bleile wrote:
>
>>
>> One big advantage of glDrawPixels is that you can use arbitrary
>> widths and heights of your image (for lazy programmers...). Textures
>> unfortunately still need power of 2 sizes (in most OGL implementations).
>>
>
> Not true.
What exactly is untrue?
> You don´t have to use every pixel in a texture.
> You can just use the lower w*h rectangles of a texture.
yes indeed.
> This wastes memory, but it works just fine. If you have
> the texture_rectangle extension then you don't waste
> the memory.
If you don't, you can waste a lot (for example PAL=720x576, needs a
1024x1024 texture), that's a pretty serious waste of texture memory.
>
>> You missed one important issue: glDrawPixels takes the image
>> data from main memory and is thus pretty slow.
>
>
> Make that "can be slow on PC consumer graphics cards".
And is slow on an Octane as well (compared to texture).
So, I would say it's not just a problem of PC's ....
> There are plenty of systems where glDrawPixels is
> lightning fast.
yes. But on which system is it faster than textures?
> In fact, the very first PC graphics cards were fast,
> it was NVIDIA who killed glDrawPixels with their TNT
> cards.
I guess that's an architectural problem of PCI cards and
the whole PC-Bus structure stuff....
Which card do you mean had a fast glDrawPixels?
Kenny Tilton
Antonio Bleile wrote:
> Kenny Tilton wrote:
> You absolutely don't have to worry. OGL takes care of that.
> For advanced control you might want to take a look on
> glAreTexturesResident and glPrioritizeTextures, etc.
Fantastic. I can keep the GUI skin resident (since it will always be
needed) to make sure it does not get squeezed out by other things with
finite lifetimes.
You know, the only reason I am mucking with OpenGL is to have a portable
graphics layer for my current project (a portable Common Lisp GUI) but I
could easily see myself getting sucked into OpenGL.
>
>
>>>
>>> If you want to draw your background just once use glDrawPixels,
>>> if you use the same image very often use a texture.
>>
>>
>>
>> At this "crawl before you walk" stage I am redrawing the whole scene
>> on each (GLUT) redisplay call. The above is encouraging in that it
>> sounds as if I can use some scheme (off-screen buffer?) which allows
>> incremental redraws of just things which have changed. But I am
>> getting fine performance so far, so I'll hold off on that a while.
>>
>
> What? :-/
>
> For simplicity I would draw the whole thing every time and
> swap the buffers when you're done (are you familiar with
> double buffering?).
Yeah, the GLUT makes that simple. I guess you meant by "draw your
background just once" you meant once per redraw?
Anyway, I am back in business. I guess for the skin I will have to waste
some texture memory if I want a single image back there, but hey, I'll
just warn users of the penalty. (Thank God for Moore's Law.)
fungus
> fungus wrote:
>
>> Antonio Bleile wrote:
>>
>>>
>>> One big advantage of glDrawPixels is that you can use arbitrary
>>> widths and heights of your image (for lazy programmers...). Textures
>>> unfortunately still need power of 2 sizes (in most OGL implementations).
>>>
>>
>> Not true.
>
>
> What exactly is untrue?
>
Keep reading...
>> You don´t have to use every pixel in a texture.
>> You can just use the lower w*h rectangles of a texture.
>
>
> yes indeed.
>
Ok, you found it.
>> There are plenty of systems where glDrawPixels is
>> lightning fast.
> yes. But on which system is it faster than textures?
>
Umm...if it has to be "faster" than textures then try
Windows GDI software renderer.
> Which card do you mean had a fast glDrawPixels?
>
eg. Permedia2