Re: Why use OpenGL (was Native Mode Handling)

Kendall Bennett wrote:
> 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. 

Any my point was that a 2D programmer doesn't have to be concerend at 
all with the 3D "cruft" in order to work with glDrawPixels, etc.


> 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.

What features is glDrawPixels missing?


> *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.

Clearly the X server's modular design will allow it to be layered 
either on OpenGL or some other type of hardware driver.  If you don't 
want to use OpenGL for your hardware interface, fine.

Personally, I'm far more interested in the OpenGL scenario.  I want to 
make sure that OpenGL meets the needs of the server in this regard.

I'd also like to see OpenGL become a standard graphics API on X, 
whether it's hardware accelerated or not.

Cairo also has it's place.  Features like cross-device support (for 
printing) and pixel-exact rasterization are pretty important too.

-Brian