Re: Why use OpenGL (was Native Mode Handling)

Brian Paul <brian-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote:

> > Thinking about this some more it would seem to me that perhaps what you
> > need is to make sure there is always a good 2D API available that is
> > implemented in terms of 3D functionality. Make sure it is easy to use
> > (or backwards compatible at least), and make sure it can be done *fast*.
> > Like I mentioned before, bitmap support in OpenGL sucks -
> 
> Can you elaborate?  I've heard this said before, but I never see
> much in the way of concrete information. 

Doing it fast via OpenGL is always painful, because glDrawPixels is 
traditionally not well accelerated (even on Windows). Part of it has to 
do with the fact that at the back end doing *everything* this function 
can do is complicated, so the hardware drivers have to know what common 
fast cases should be accelertaed, and the call code needs to know what 
state to set up in order to get on the fast path.

> > One way of thinking about this is that as a 2D programmer, if I want to
> > draw a blended 2D bitmap, I don't want to have to set up a geometry
> > pipeline, load a texture map, bind the texture map, set up the 3D
> > rendering engine state and then finally draw some 3D triangles to get my
> > blended bitmap on the screen. Rather I just want to call something like
> > BlendBitmap() that will take my bitmap and blend it onto the screen.
> > Whether the internal implementaiton does all of the above is irrelevant,
> > so long as the 2D programmer does not have to deal with all the 3D
> > cruft.
> 
> What's wrong with this:
> 
> glEnable(GL_BLEND);
> glWindowPos2i(x,y);
> glDrawPixels( my_image );

What about all the rest of the state that has to be set up correctly to 
ensure this works properly? There are all kinds of raster modes and 
scaling that can affect this call that needs to be accounted for, plus 
you need to set up the blending pipeline correctly. On top of that all 
this ends up going through the geometry pipeline (since the vertices 
*can* be transformed in OpenGL for this function I believe). Since most 
developers using a 2D API could care less about sub pixel precision etc.

Also using glDrawPixels() the only option you have is to draw the bitmap 
from a image buffer that you pass to the OpenGL API. There is no way to 
create a bitmap and have the contents stored in offscreen video memory 
somewhere, and then be able to draw directly from the offscreen buffer 
somewhere else in video memory using the hardware. To do that, you need 
to stuff your bitmap into a texture (with all the associated hazards of 
texture dimensions), bind it to the pipeline and then draw some polygons. 
Like I said before, whether intenally a DrawBitmap function does all of 
that is irrelevant - the 2D programmer does not want to have to deal with 
that level of complexity.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~