[cairo] Re: [Mesa3d-dev] Points in Cairo Glitz paper

[Jon Smirl]

The image compositing model is a very core part of render. If it isn't easy to
accelerate on common hardware then we're going to have performance trouble.  Do
low end cards have four texture units?

--- Ian Romanick <idr at us.ibm.com> wrote:
> Jon Smirl wrote:
> > Can multi-texture do this? I believe it is described more in the original
> > Cairo paper:
> > http://www.freedesktop.org/Cairo/xr_ols2003/
> > 
> > If not this is something that should be discussed at the conference.
> 
> It depends.  It would depend on how the images are stored and how many 
> masks are used.  I'll see if I can catch up with keithp tomorrow on 
> #freedesktop and talk to him about it.
> 
> I think you'd need 3 texture units, and in some cases 4.  In some 
> (most?) cases you could get by with less texture units by using multiple 
> passes.  It should be doable with just ARB_multitexture and 
> ARB_texture_env_combine, but any of the fragment program extensions (the 
> ATI & NV extensions or the ARB extension) would make it much, much easier.
> 

Jon Smirl wrote:
> I'm reading the Cairo Glitz paper and somethings caught my eye. Is there a
> better way to do this in OpenGL that doesn't involve intermediate buffers? Or
> could this be fixed by changing the compisiting process?
> 
> Here's a description of the image compositing process.....
> 
> To composite one surface onto another with OpenGL, texturing of a rectangular
> polygon is used. This means that the source surfaces must be available as
> textures. The default method for making a surface available as a texture is to
> have the graphics hardware copy the pixel data from a drawable into a texture
> image. As this is a relatively slow operation, glitz does its best to minimize
> the area and number of occasions for this copy operation. On some hardware, a
> feature called render-texture is available that allows glitz to completely
> eliminate the need for this copy operation and instead use a pbuffer directly
as
> a texture. 
> 
> The optional mask surface that can be provided to the general composite
> operation creates some additional complications. The source surfaces must
first
> be composited onto the mask using the Porter-Duff in-operator and the result
> must then be composited onto the destination. The default method for handling
> this is to create an intermediate off-screen surface, which can be used for
> compositing using the in-operator. This surface can then be composited onto
the
> destination with an arbitrary operator for the correct result. 
 >
> The best way to do this would be to perform compositing with a mask surface
> directly without the creation of an intermediate surface. Even though the
fixed
> OpenGL pipeline does not seem to allow for such an operation, glitz is able to
> do this on hardware that supports fragment programs. Fragment programs allow
for
> fragment level programmability in OpenGL, and in combination with
> multi-texturing, glitz can perform composite operations with a mask surface
very efficiently.




=====
Jon Smirl
jonsmirl at yahoo.com


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash