[cairo] recursive quad-tree, or bounding box of changed area during drawing?

Carl Worth cworth at cworth.org
Sat Jun 3 15:11:56 PDT 2006


On Fri, 2 Jun 2006 12:37:35 -0400, "Mike Shaver" wrote:
> 
> On 6/1/06, Federico Mena Quintero <federico at ximian.com> wrote:
> > Blitting is not going to be your main performance problem, unless your
> > blitter is absolutely horrible.  You need to do profiling on the whole
> > pipeline.
> 
> I'm not sure entirely what part of the stack you mean here when you
> say "blitter", but certain some operations that I would expect to be
> simply blitting are quite slow -- I might even use your "horrible" --
> term when using the xlib cairo back end.

I think you are agreeing with Federico here. I believe he is saying
that the time required for cairo to compute a result might overwhelm
the time required to copy it afterwards, so trying to optimize the
copy might be premature.

> http://people.mozilla.com/~vladimir/misc/xlib-results.html and the
> first two lines, especially.

Those results are aberrant. There is no good reason that the xlib
backend should ever be significantly slower than the image backend,
(since the X server has access to the same software rendering code
that cairo's image backend has). So the cases where xlib is
under-performing the image backend by 10x are truly broken somewhere.

The encouraging thing about that awful result is that by definition
there must be an easy fix for it. Here are three possible scenarios I
can think of off the top of my head:

1) Someone implemented "acceleration" hooks for Render that end up
   being slower than the dumb-as-can-be software fallbacks for Render
   in the X server, (that is, the code that's the same as pixman).

   Hopefully, that isn't the case. If so, somebody somewhere should
   start looking for new employment.

2) The particular X server being used here doesn't implement Render at
   all and cairo is adding fetch/store overhead to rendering it is
   doing with client-side software anyway.

3) Cairo is just doing something horribly stupid, and a profile should
   reveal it.

In any of those three cases the answer is just to find the stupidity
and stop doing it.

That page doesn't mention the relevant details, but if I recall
correctly, Vlad originally mentioned that the table resulted from
using an NVidia card, (binary-only driver? I don't recall).

Just as soon as I finish up the 1.2 release I'll be switching to
working on cairo performance full-time. So I'll be making my own
measurements of things at that point.

In the meantime, now would be a wonderful time for anybody to start
collecting profiles of things they consider interesting cases for
cairo. The more concrete data you provide to performance problems in
cairo, the more likely your hot issues will get fixed.

So grab Vlad's benchmarking suite, or fire up your favorite
cairo-based application or desktop environment, then let loose
oprofile, sysprof, gprof, or any other favorite performance-
measurement tool and let's find out what we need to do make cairo go
fast.

Should be a lot of fun,

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060603/113a535d/attachment.pgp


More information about the cairo mailing list