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

[Behdad Esfahbod]

On Thu, 2007-08-30 at 16:04 -0400, Carl Worth wrote:
> On Thu, 30 Aug 2007 14:12:56 -0500, ionous wrote:
> > I have a version of the optimizations I described up and running now -
> 
> Hello again!
> 
> First off, thank you very much for going back to non-HTML mail. That's
> really appreciated, (it's quite hard for me to not just delete HTML
> mail unread).
> 
> > I've had some problems getting the very latest source ( pixman in 
> > particular, but also some minor stuff with the tests ) compiling under 
> > windows ( both vc and cygwin/gcc ) -- I will detail and ask for help in 
> > a separate mail.
> 
> Thanks, please do.
> 
> > For the moment, tho, I've attached the source rather than git patch,
> > in case anyone wants to take a look.
> 
> The patch would actually allow me to take a look, (read it in my email
> program, read only the actual changed code, reply to actual quotes of
> the code, and if desired, apply the patch for testing). By contrast,
> complete source code files aren't of much use for any of those
> purposes, (particularly zipped).
> 
> And all of that holds even if the code is preliminary and not intended
> for being applied to cairo's tree---a patch is still greatly preferred.
> 
> > All in all looks pretty good -- checking out some stress tests with more 
> > heavy uses of primitives would be interesting.
> 
> Yes, in general I'm always in favor of improving things. Keith wrote
> the original chunky-path storage, and Behdad rewrote it later to
> reduce memory consumption. So another rewrite now to improve it more
> sounds great. Maybe Behdad will have some comment, (or maybe he too
> will wait to see a patch).

I've wanted to reply to the original mail.  Doing it now.


> > Open Questions:
> > * Is the code managing reverse traversal of paths necessary. I didn’t 
> > (re)implement it in the attached because no one appears to be using it.
> 
> If there are no callers then please remove it. As that's a logically
> separate step, please do that as a separate patch/commit before your
> subsequent work.
> 
> > Regarding the attached code -- it includes a whole bunch of logging code 
> > that while useful does make the code less maintainable -- I will 
> > probably rip it out before making a real patch.
> 
> And that sounds like something that would work well has a third
> commit, (so that you could submit the complete patch series with three
> commits, but perhaps only the first two would be intended for/applied
> to cairo itself).
> 
> > * What size should cairo_path_fixed_t be set to? comments indicate 512 
> > bytes is desirable but I don't think gcc nor visualc achieve that. gcc 
> > -- assuming my macro expansions are right -- comes in at a very odd 499 
> > bytes.
> 
> I have no suggestion here. Behdad?

If you are talking about the current macro, it leaves 2 * sizeof (void*)
for the libc memory bookkeeping.  So, starts with 504 bytes really.


> -Carl
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759