[cairo] path storage optimizations ( was: how to propose a change? )

[ionous]

Vladimir Vukicevic wrote:
>> all, re: is it worth it?
> 
> 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.  

short answer -- no not significantly and for exactly the reason you say. 
  every little bit helps is my feeling but the cases im dealing with are 
pretty simple so far.  i'd like to run it through a stress test to see 
what the edge cases are like tho.

slightly longer answer -- i think that a collection of memory allocation 
callbacks that make specific requests for specific structure types could 
facilitate memory pooling and reuse with cairo on consoles.  i haven't 
actually looked at this yet -- swapping out malloc, and using allocation 
  request size as a key can work just as well for libraries that don't 
provide that level of granularity.

> The LINE_SEGMENT/CURVE_SEGMENT suggestion in particular seems like an 
> optimization for disjoint lines/curves, which I think are fairly 
> uncommon in paths.

i agree -- in actual coding tho it played out nicely -- it wound up 
removing the need for any explicit movetos in the streams, and made the 
code itself look self similar.

>> 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.

awesome -- that will hopefully do the trick.