New glucose code

Alan Hourihane alanh at
Thu Mar 29 03:59:04 PDT 2007

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.


More information about the xorg mailing list