New glucose code

[Alan Hourihane]

On Thu, 2007-03-29 at 13:51 +0300, Daniel Stone wrote:
> On Thu, Mar 29, 2007 at 11:37:04AM +0100, Alan Hourihane wrote:
> > On Thu, 2007-03-29 at 06:18 -0400, Zack Rusin wrote:
> > > One thing I wasn't 100% convinced of was how well will it perform when going 
> > > through whole OpenGL stack when doing simple (and small) blits or the like. 
> > > It's not that I couldn't sleep because of it at night (I don't sleep for 
> > > other reasons) but I was contemplating using DRI directly in those cases.
> > 
> > Some of the traditional fills/blits can be really slow. But they are
> > even slow in Xgl as well, so it's not glucose's fault. It's more to do
> > with optimisation of the 3D drivers now, and possibly even writing some
> > extensions that may help with utilizing the 2D engine when one is
> > actually available :-). But we're compositing, so it's bound to be
> > slower than the traditional methods. But I guess as hardware performance
> > improves so will this acceleration architecture.
> 
> Yeah, but in some cases (say, a 10x10 blit/fill), it's not necessarily
> worth the overhead of setting up and tearing down for the simple op,
> particularly if you've got an active client and thus lock contention.
> So it needs some smarts as to when to just deal with it unaccelerated.

Absolutely. This is where we need to start to optimise as I've said.

Alan.