> Ingo Molnar [Thu, 21 Apr 2005]:
> I just checked how the kernel repository looks like with it, and
> i'm impressed! The GUI is top-notch, and the whole graph output and
> navigation is very mature visually. Kudos!
Thanks !
> - there doesnt seem to be any performance difference between non-colored
> and colored rendering - so you might as well want to make 'color by
> author' (or color by branch) the default coloring, instead of
> uncolored?
It has to call `cat-file commit' for each commit id to get the author ... it's just that's a lot of forks.
> - naming the boxes by key is quite meaningless. It would be more
> informative to see the author's email shortcuts in the boxes. Also, it
> would be nice to see some simple graphical feedback about the size and
> scope of a changeset, without having to zoom on it.
That's interesting. What do you mean exactly by scope ?
> i guess you know it, and i'm definitely not complaining about prototype
> code, but rendering is quite slow: drawing the 340 changesets in the
> current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the
> full kernel history (63,000 changesets) would take more than 45 minutes
> on this box.
>
> the current rate of kernel development is ~2000 changesets per month, so
> drawing the kernel history will get 3 seconds slower every day - it will
> exceed 1 minute in 20 days, so this will become a pressing issue quite
> soon i suspect.
Right, it is slow. From what I could understand with a bit of profiling, the problem is with the "text" canvas item for the boxes' labels. I guess libgnomecanvas isn't using Pango properly or something: it lookups the font with fontconfig each time I create such an item. I'm not sure what I can do about this.
Also, there's a -noaa option that draws an non-antialiased canvas : it's noticeably faster (and uglier too).
> Ingo Molnar [Thu, 21 Apr 2005]:
> another thing, when i 'zoom out' of the graph far away (so that the
> whole graph becomes visible on the screen), i'm getting lots of such
> error messages:
>
> *** attempt to put segment in horiz list twice
Yes, this message must come from one of the libraries (libart most probably)
> Ingo Molnar [Thu, 21 Apr 2005]:
> is the 'diff with ancestor' feature supposed to work at this early
> stage? (it just does nothing when i click on it. It correctly
> offers two ancestors for merge points, but does nothing there
> either.)
It works with Petr Baudis' git-pasky (it calls `git diff'). I don't know how to do that with the canonical git.
Thanks for the suggestions,
Petr Baudis