Re: Better gradient handling (migration/fallbacks)

2008-11-16 Thread Joel Nowotny
We tried to use gradients to skin our application, but performance was so bad we soon gave up (on i855GM). Oprofile showed the majority of time was spent in memcpy. It would be great if these problems could be resolved in the upcoming xserver release. Great to hear code has already been

Re: Better gradient handling (migration/fallbacks)

2008-11-14 Thread Clemens Eisserer
Hi, Do you think there is any chance of getting the gradient hooks into 1.6? Would not be too bad if no driver is able to accalerate it for now, but at least users would not need xserver 1.7 to get accalerated gradients. Distributors usually tend to update drivers, but they almost never switch to

Better gradient handling (migration/fallbacks)

2008-11-13 Thread Clemens Eisserer
Hi, I've experienced some performance problems with gradients when working on the xrender/java2d backend. A typical problematic case is when mask and desitation picture were in VRAM, and a gradient is used as source. As far as I understand this causes mask and dst to be moved out into sysmem,

Re: Better gradient handling (migration/fallbacks)

2008-11-13 Thread Eric Anholt
On Thu, 2008-11-13 at 14:30 +0100, Clemens Eisserer wrote: Hi, I've experienced some performance problems with gradients when working on the xrender/java2d backend. A typical problematic case is when mask and desitation picture were in VRAM, and a gradient is used as source. As far as I

Re: Better gradient handling (migration/fallbacks)

2008-11-13 Thread Clemens Eisserer
We just need to accelerate gradients, and is where any effort in software should occur. It's on our schedule, but not for quite a while. Setting up the X Server to allow drivers to request gradients was easy last time I did it, though I've misplaced the branch it looks like. Then someone