[cairo] Cairo rendering on ARM

[Daniel Amelang]

On 5/24/07, Bob Murphy <bob.murphy at access-company.com> wrote:
> I rendered three passes of over 250 SVG images into GdkPixbufs

Out of curiosity, why are you rendering to a GdkPixbuf instead of to a
cairo image surface or a cairo xlib surface? On a related note, I've
found that compositing GdkPixbufs within the X server is quite slow
(due to no fast path for fbComposite on ARM), so you want to be
careful that that isn't your actual bottleneck.

> So here are some questions:
>
> 1. Does --disable-some-floating-point actually do anything? I saw a
> note that it had been added in an earlier version of Cairo (1.3.6?)
> for future use. And I tracked its effects through configure and so
> on, in both Cairo 1.4.4 and 1.4.6, and it looked to me like this
> option doesn't currently affect the compile or lin.

Currently it doesn't do anything. At one point, we thought that some
of the new paths to avoid FP would slow down devices with FP, but all
of the new paths ended up performing faster or the practically the
same on FP devices, so the flag hasn't been needed yet.

I do know of someone that is looking into providing a fixed-point path
for some of the curve/arc/spline code that is FP heavy. So I think
that the flag will be of some use in the near future.

> 2. Are there any other ways to enable optional performance
> enhancements for devices without FPUs that I've missed?

Nope. Well, you should always be careful what code is riding above
cairo, but that's about all you can do at this point.

> 3. Generally, what kinds of performance enhancements have been made
> for non-FPU devices?

Text rendering, and floating-point to fixed-point conversion (which
happens on several common API calls).

> I'm wondering if perhaps they've all been done
> in areas that  simply don't affect SVG rendering.

The term "SVG rendering" is too general for the purpose of this
discussion. First of all, I don't know what library you are using to
interpret the SVGs as cairo calls, so there's that factor. Second, SVG
is only a format; it doesn't imply anything about content. It's the
content of the SVG that determines what calls are made to cairo, and
thus the performance.

For example, if your SVG contains a lot of curves, it's going to be
slow, regardless of the improvements we've (somewhat recently) made.
If it contains radial gradients, it'll be really, really slow, since
the radial gradient code is very FP-heavy.

Besides those cases, though, cairo should perform pretty well on
FPU-less devices. So unless your SVGs exercise the code paths
mentioned above, I don't think that slow performance should be blamed
on floating point use.

We're happy to look over your profiler output to see what could be
done to improve performance. Oprofile is the (mine, at least)
preferred profiler, as it is system wide and could pick up on
performance problems that are actually down in the X server. Either
way, you can't know for sure what is slowing your app down unless you
use a profiler. Humans (in general) are really bad at guessing what
the actual bottleneck is.

Dan Amelang