[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 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
Attachment:
pgpeW82yg3RbU.pgp
Description: PGP signature