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

[Alex Deucher]

--- Jon Smirl <jonsmirl at yahoo.com> wrote:
> 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?

no. many have only 2.  some older hardware only has 1 (although in that
case, it can't do multitexture).

Alex

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