Mark Vojkovich <[EMAIL PROTECTED]> writes:
> On 30 Dec 2001, Owen Taylor wrote:
>
> > [2] Right now, to get decent performance, the source must be
> > in system memory - we clearly need this for decent performance
> > for the software fallback, and XAA also only supports this.
> > For the local rendering case, we can enforce the source
> > being in the right place by using a ShmPixmap. For the
> > remote case, we have no way to enforce this, and given
> > sufficient video ram, we'll get bad performance.
>
>
> It wouldn't be too difficult to force sources out of video ram
> when they are used in composite operations. I do that for other
> cases such as offscreen pixmaps being used as tiles in GCs used
> on system memory pixmaps.
>
> Yes, XAA assumes all data is in system memory and doesn't
> optimize when both source and destination are in video ram, which
> should be the fastest case of all. The drivers can hook this
> high enough to do this themselves, but XAA doesn't have low-level
> functions to do this. I can add this to NVIDIA's drivers easily
> enough, but the problem is testing. I've hardly seen anything
> resembling a test or performance suite for Render. I can't accelerate
> anything I can't test, which is why XAA will only accelerate some
> very simple cases.
It's perhaps a bit of a chicken and egg problem ... it's hard to write
accurate performance tests until there are apps, and no compelling
reason to write apps using the more complicated bits of RENDER as long
as its faster to do things on the client side.
For the near term, GTK+ is going to only be doing simple
stuff:
- Drawing text using Xft (Saturate and Over)
- Compositing (Over) RGBA data sent from the client onto pixmaps.
- Compositing pixmaps over pixmaps (a fade-in menus, tooltips hack)
If I can find the time (hah), I'll look at adding some test for the second
into x11perf.
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
