[cairo] path storage optimizations ( was: how to propose a change? )
vladimir at pobox.com
Fri Aug 31 10:00:17 PDT 2007
> all, re: is it worth it?
> i think so. whether things like a tad fewer allocs and a tad less
> memory used trump code maintenance is a definitely an important
> question. in this case, i think the new code is just different than the
> old code, not less maintainable. previously you had to understand the
> why of checking for flags like "current point" and peeks for "move tos"
> -- now you have to grok a small state machine, and a null terminated
> list of draw commands. neither is particularly problematic, tho both
> require some thought.
Does this actually show up in real-world preformance, though? I
understand that there are serious memory fragmentation and other issues
on consoles, but it doesn't look like these changes would actually help
with any of that: they would just achieve a very modest memory savings
but still keep the exact same current allocation scheme. The
LINE_SEGMENT/CURVE_SEGMENT suggestion in particular seems like an
optimization for disjoint lines/curves, which I think are fairly
uncommon in paths.
> once i get back from my trip - i will figure out the build issues, make
> patches against latest, and re-post so y'all can take a closer look-see.
I've got updated win32 makefiles for pixman and for cairo that I'll be
checking in shortly; you'll need to grab a win32 build of libpng and
zlib and make them available in $INCLUDE/$LIB, but other than that it
should build cleanly then.
More information about the cairo