[Xorg] Using transformations in the render extension

[Lars Knoll]

On Monday 16 August 2004 11:41, Eric Anholt wrote:
> On Mon, 2004-08-16 at 02:16, Lars Knoll wrote:
> > Hi,
> >
> > we did some experimenting trying to use transformations provided by the
> > render extension on pixmaps. What we found is that they currently are
> > about a factor of 5 slower than sending the data over to the client,
> > doing the
> > transformation there and sending it back (for the "nearest" neighbor
> > filter).
> >
> > I digged a bit through the XServer code, and it seems that we take the
> > worst possible code path whenever a transformation is involved (going
> > into fbCompositeGeneral, and using function pointers for all operations).
> >
> > The other thing I noticed while looking through the code is that
> > PictOpSrc always seems to go through the fbComposeGeneral method (even
> > without transformations).
> >
> > Wouldn't it be worth optimising PictOpSrc without transformations, and
> > both PictOpOver and PictOpSrc for affine transformations (or at least
> > scaling operations)?
> >
> > I know that it would be best if the drivers started supporting these in
> > hardware, but as it currently looks to me most of them do not have the
> > support yet, and it would be great if the software fallback would not be
> > slower than what one can achieve on the client.
>
> Your DDX should be handling PictOpSrc in the no-transform, no-repeat,
> same-format case by using its normal CopyArea acceleration.  XAA was
> fixed up to do this for the next release.  Repeating 1x1 PictOpSrc
> should be done using the normal solid fill code as well (in the absence
> of something better, which a general render acceleration might be).
> Kdrive does both of these.

Great if it does. I just couldn't find the code path, as CompositePicture() in 
render/picture.c just calls ps->Composite, which I thought would map directly 
to fbComposite in fb/fbPict.c for most drivers. In there I couldn't find any 
code for PictOpSrc.

> There are far too many possible Render combinations to provide optimized
> paths for all of them in software (without codegen, which is probably
> more work than it's worth).  We weren't seeing too much PictOpSrc
> before, but now we are with Composite.  We weren't seeing much use of
> transforms, and now we are seeing some (and will be seeing more and more
> for eye-candy things).  

That's also a bit a Hen and Egg problem. As long as transforms are slow people 
using transforms will probably continue doing them on the client side. 

I agree that there are way to many combinations to implement optimised paths 
for all of them. I was mainly thinking about the scaling or rotating pixmaps 
which is not all that uncommon. I know for example that KDEs style engine 
needs this in some places. Currently they keep the image data on the client 
side, scale it to the size they need there, and send the transformed pixmap 
over to the server for blitting. Most of it doesn't even involve an alpha 
channel.

> I expect that as people find more and more neat 
> effects to do with Render thanks to Composite, we'll have to keep adding
> specific case improvements in software unless we improve software
> compositing generally so that it's much closer to optimal.
>
> Keith told me his plans for the general compositing code the other day,
> involving converting the general code to operate on "patches" instead of
> pixels.  With that, then we can have a single set of fast vectored IN
> handling that operates on patches, two sets of each OP (component-alpha
> and non-component-alpha), and patch-loading and -storing functions which
> will be able work on the framebuffer *much* faster than currently
> possible per-pixel.

That sounds great :)

> Note that I expect to see much more Render acceleration in drivers once
> we get an acceleration architecture that's designed with Render in mind.

I expect this as well. I was mainly thinking about the software fallback. 

Thanks for the info,
Lars