XRender acceleration

[Zack Rusin]

Hey, [*1]

we're doing better and better at accelerating XRender. Muchas problemos that 
we have on the toolkit level are caused by the fact that we (*2) have no idea 
what is accelerated. 

What happens right now is that both toolkit and driver developers pick, pretty 
much at random, paths that they like. Unfortunately they often don't match 
and we end up with a driver nicely accelerating operations that are never 
used while toolkit neatly using operations that are not accelerated.

Not that playing guessing game isn't a whole lot of fun (we could have office 
parties where people get candy for finding accelerated paths on driver x) but 
how about if we make it a little bit more boring and add some more rigid 
framework around XRender that defines those things.

For a while I thought about adding XRenderIsAccelerated call where you pass, 
op, src, dst, mask and it checks whether the current op with the given 
surfaces can be accelerated. This has two unfortunate sideeffects:
- there's a butt (*3) load of combinations. Not only ops but also alpha 
handling, formats and filters matter and give us quite a lot of paths there.
- It doesn't make it any easier to figure out what operations are most likely 
to be accelerated. It doesn't tell us what things the driver developer should 
more likely implement to get a lot smoother desktop experience.

Right now I'm thinking that the best solution might be defining XRender 
Level's. I just talked to Fredrik and basically the scheme I think would make 
the most sense is this:

- Levels would group XRender functionality in a way that allows clearly naming 
of them.
- It's mandatory that individual levels are defined _very_ strictly. 
- Drivers advertise supported Levels. Desktop environments/toolkits define 
levels they need for best experience. This way a driver developer can take a 
toolkit/desktop environment and see what exactly is needed to make it work 
and work fast. While toolkit/desktop developers look at levels and see what 
are the bounds they need to be working within. This gives both group a clear 
and finite set of operations they should be working with.
- Benchmarking application. It's a lot easier to check for "Level 1" 
acceleration than to check "for everything that is used by toolkits/desktops 
and accelerated by drivers".

So for example:
Level 1 would include only the core Porter&Duff operators. No filters. No 
different ways of handling alpha. PictStandardARGB32 format. No 
transformations.
Level 2 would for example add transformations.
Level 3 would for example add filters.
Level 4 component alpha. And so on. 
...
Level X, where X is the last possible level defined - as set by whatever type 
that holds them. Level X would mean that whole freaking current XRender 
version is accelerated and I get cookies [*4].

Now before I actually go and do that (define levels, write them up, add level 
check call to render, change drivers and write the test app) I'd like to hear 
opinions about this. Does anyone see a better solution of figuring out what 
is accelerated (from the toolkit side) and what should be accelerated (from 
the driver developers side)? Comments? Opinions? Beauty tips [*5]?


[1] Platonic greeting.
[2] As an exercise for your intelligence I'm using "we" interchangeably with 
respect to both "toolkit" and "X" developers since I'm a questionably proud 
member of both. 
[3] For very large butts. 
[4] Don't judge me, I like cookies.
[5] Not that I need any since I'm absolutely gorgeous.