Re: "floccinaucinihilipilification", or "convolutions, blocking, and windows server 2003"

On Mon, Mar 15, 2004 at 07:16:43PM -0800, Keith Packard wrote:
> As for chaining convolutions, I suggest that a combination of convolutions
> should itself be a well defined convolution.  Hence, we can simply compute 
> the overall convolution on the client side.

Do you mean that we should combine all of our ops into a single matrix, or
that we need to have a special type for various combinations?  IN the former
cases, see "matrixes are actually very slow and can be optimized away in most
cases", or if you mean the latter, I'm interested to hear how you think that 
should look.


> > I wanted to see wether people wanted this complexity of operations before
> > I spent the time to clean it up.
> The answer is "no", we don't want to see all of that complexity in the 
> server.  Remember that our goal here is to:
> 
> 	a)	Reduce network traffic
> 	b)	Get at hardware acceleration

I would contend that nothing here fails either of these goals, although I'll
admit that (b) is harder on current generation video cards if the programmer
tries to do something complicated - but that's the programmers perogative, 
and it's entirely possible that we *can* combine some cases into hardware 
right now (desaturate+blur is a good example of where this is true).  Since
render ops don't seem to be asyncronous, and latency is just as important 
on interactive apps, having multiple ops could help (a) as well.

> An explicit non-goal is to provide an easy to use API at this level -- 
> that's a problem for higher level libaries (like cairo).  Given that we 
> can even use intermediate buffers if necessary without increasing network 
> traffic, and given that hardware is unlikely to support combinations of 
> filters any time soon, it seems clear that a single filter should suffice.

I think we all agree that the API is not what would be called "easy to use".
While I disagree that "powerful" shouldn't be a goalm, this isn't my project,
so that's not my call :-p.  That said, I think this provides advantages in
both caching for performance, and even now some operator sets can be combined
in hardware into a single call.  I believe an optimized hardware version of
this could run very fast without sacrificing the power and resoting to 
exposing hacks to userspace.

Particularly given that there will be 10 fifferent implentations of these
hacks to optimize instead of just this one :).

> Can you list the filters that you have implemented?  We should be able to 
> figure out how to parameterize them pretty easily.

Right now, the following are implemented and seem to work:

SimpleConvolution (FIR matrix)
SplitConvolution (one FIR matrix per channel)
SquareBlur (special case 1/1/1/1/1 FIR matrix)
RoundBlur (special case circular blur matrix)
FastBlur (two pass simple blur)
Desaturate (just what it says on the box - however, youcould
            get the same effect by blitting ot a greyscale plane
	    if we're not having multiple convolutiosn anyhow)

The following are partially implented, but have issues:

GaussianBlur (actually a linear matrix, not a gaussian curve, and should 
              use a two pass gaussian for the fast version, and have 
	      seperate slower IIR and RLE implentations)
Arbitary (Implentation of a texture shader, basically - should be able to pass
          directly through to GL/whatever.  This is currently missing, uhm, most
	  ops.  Given the complexity I plan to make this fast, I expect it wouldn't
	  be well recieved.  :)

The following really need to exist, but only exist in old files form 
teddy painter (don't ask) right now:
IIR Matrix
RLE Matrix


	  	-- jj
--
Jaymz Julian - Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people. 
 Very few people have `I want to be killed and eaten' on their cards, 
 so Hannibal is out of a job." - http://cards.sf.net