[cairo] Re: Qt Vs Cairo performance comparison

[Carl Worth]

[I'm cross-posting this reply to the cairo list since I'm talking
about some snapshot plans that that audience might be interested
in. Readers might want to see my first post in this thread at:

http://mail.gnome.org/archives/performance-list/2006-October/msg00053.html

]

On Tue, 24 Oct 2006 13:30:19 -0700, Carl Worth wrote:
> Hmm.. I thought Zack was making it available. He did mail me the code
> he was using for cairo with the polygon data (the day before he
> published the tests).

Or rather, he sent me a URL. And I think the same URL appears in his
blog post(s). So I don't have anything that's not available to the
world.

> The 3 reported polygons probably all fall into the case of not being
> very common. But it is important for a renderer to be scalable to
> avoid performance traps, (and I don't know where the bounds for
> "realistic" is in the number of vertices).

On a related point, I am still very interested in seeing "real world"
polygons that stress out tessellators. Anything that has a large
number of edges or a large number of intersections and appeared in
"the wild" as opposed to "the lab" would be very interesting.

And not just polygons, either. In cairo land, we are interested in any
real-world performance scenarios that are causing problems. We've been
told several already:

	* systems without hardware floating-point have lots of
          problems, (particularly with text)

	* gradients are slow

	* tessellation is slow

We have patches in hand that address each of these to some extent,
(though more could be done for all of them as well). I'm working to
land these existing patches this week with an eye toward releasing a
1.3 development snapshot showing some of the improvements made since
1.2 by this Friday.

Oh, and I think that mozilla has hit some test cases that stressed out
the tessellator. Yes, I just found some by looking for
cworth at cworth.org as the CC. Here are some of the cairo-related
performance bugs I found there:

SVG rectangle hangs Firefox when scaled really big
https://bugzilla.mozilla.org/show_bug.cgi?id=306649

  In this one, the stroke operations gets really slow if line width is
  made _huge_, (convex hull computation for pen takes a long time).

A very slow SVG file with <path>s
https://bugzilla.mozilla.org/show_bug.cgi?id=332413

  This is one where the tessellator was profiled to be a problem. I'll
  grab these paths and shove them into cairo's performance suite.

Speed up _cairo_fixed_from_double
https://bugzilla.mozilla.org/show_bug.cgi?id=311980

  This is an important one, and one which will be particularly
  interesting to the people using embedded systems that are allergic
  to floating-point. My comment in the bug still stands:

	before I commit this to cairo proper, I'd like to see this
	version made conditional on a configure-time check so we have
	better assurance that it will actually work on a wide range of
	platforms.

  I still haven't seen a patch with that check submitted, and I'd like
  to have it.

  Oh, and I used to fear that run-time checks for features at
  configure-time would be problematic, but I've recently found that
  scratchbox magically supports these for embedded development. So I
  don't have a problem relying on these and telling users to either
  1. Compile natively. 2. Cross-compile with scratchbox. or 3. Compile
  either way and hand-write the config.h settings as appropriate.

> Like I said, I've got the polygon data and I told Zack I was planning
> to integrate it into cairo's performance test suite.

I may not do this now, if only because the paths add 4MB of data to
the test suite, and I'm not convinced of their real-world
applicability. So I don't know how much it would help to make them a
permanent part of our testing.

> As for numbers, the new tessellator still needs some work, (which is
> what I explained to Zack and he mentioned). Numbers to come soon.

I will still do testing with these polygons and publish some numbers
for them when the new tessellator lands in cairo.

-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/20061024/d660be64/attachment.pgp