Re: Why use OpenGL (was Native Mode Handling)

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

> > Doing it fast via OpenGL is always painful, because glDrawPixels is
> > traditionally not well accelerated (even on Windows).
> 
> Actually, it's not too bad with recent NVIDIA and ATI drivers (for 
> example).
> 
> The basic task is to quickly move image data from user space to
> VRAM. There's no reason why OpenGL should be slower than any other
> graphics library/API for comparable operations. 

No reason except that there are a lot more layers of software to get 
through. But if you spend the effort to do a fast path for the operations 
that need to be fast, I agree it could be made to work.

> > 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.
> 
> The GL_ARB_vertex_buffer_object extension will probably soon have
> a layered extension that will effectively let you store an image
> in video memory and reference it with glDrawPixels.  It would be
> analogous to X's Pixmaps. 
> 
> A smart display list implementation could do this too.
> 
> You might say that this sounds complicated.  But how would you do this
> with any other graphics library?  

My point is that a 2D programmer does not want to much around directly 
with glDrawPixels() and all the other related 3D cruft to make this work. 
As it stands today, glDrawPixels is not powerful enough to do everything 
a good 2D API will need, but if you add offscreen buffer support so you 
can store images in video memory and then use glDrawPixels, that is a 
good step in the right direction.

*If* you build the system so that you can do fast system->VRAM bitmap 
copies (with blending etc etc) as well as fast VRAM->VRAM bitmap copies 
via an OpenGL back end, just don't force people to have to use that back 
end. Instead build a standard 2D API (like Cairo for example) that 
abstracts that mess from the programmer who doesn't want that level of 
detail.

> With Xlib you'd use a Pixmaps. You'd create a pixmap with
> XCreatePixmap(), load its contents with XPutImage(), then draw it
> to the framebuffer with XCopyArea().  Anyone who's done this knows
> that it's not exactly simple. 

I never said XLib was a good 2D programming API ;-)

On the other hand doing this with MGL is real easy ;-)

> Incidently, using texture maps to store images on the server side
> and drawing them with a textured polygon might be substantially
> faster than a conventional blit.  Does blit performance on modern
> cards approach the giga-pixel fill rate that can be realized with
> texture mapping? 

Yes, for the most part. I do agree that using a texture map in offscreen 
video memory to do the back end of 2D operations can be more powerful 
than using the built in 2D functions. On current hardware I am not sure 
it would be faster, but it may be (certainly is not any slower from the 
tests we have done with DirectX on Windows). But using the 3D engine to 
perform 2D operations and requiring the entire OpenGL rendering pipeline 
are two different problems IMHO.

> The other advantage of texture mapping over glDrawPixels (for
> images drawn more than just once) is the fact that OpenGL can
> reformat the image data if it's not in the ideal format. 

Yep. We have been using the 3D engine on DirectX to prototype exactly 
that type of operation for our SNAP drivers ;-) But once again the 
intention is to use the 3D engine to enable cool 2D functionality, not to 
require the entire OpenGL rendering pipeline to make this work.

> To summarize my position:
> 
> - OpenGL's API is pretty simple for most things (far simpler than
> Xlib, for example).  You can generally ignore the parts that you
> don't need. 

> - There's no intrinsic reason why OpenGL should be slow when it
> comes to conventional 2D image operations. 

No, it is just a lot more complicated than your average 2D driver. If we 
consider that very few quality XFree86 drivers exist because many people 
don't know how to get started developing them, if a 3D engine is now a 
requirement the barrier to entry just got a lot higher.

> - We have the know-how to optimize some of these things in our GL
> drivers.  It's just a matter of finding the time.  I bet that if
> we implemented fast glDraw/Copy/ReadPixels in one of the DRI
> drivers, other people could adapt the implementation to other
> drivers pretty quickly. 

Yes, I imagine so. We do in fact plan to make sure this stuff runs fast 
in the SNAP 3D drivers we are working on, so hopefully we can help in 
that area at least.

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! ~