On 8 Aug 2003, email@example.com wrote:
>> While preparing to integrate the parenting code with the diagram tree
>> (making it an actually tree), I ran across a rather obvious bug in using
>> the diagram tree with groups and undo. Curious that nobody has
>> mentioned this bug, I would like to hear how many actually use the
>> diagram tree in their work? And if the diagram tree became more
>> tree-like (i.e. with groups and parents forming extra branches), would
>> more people use it?
> I use it often on a huge UML diagram (~334 classes), mainly to navigate
> to the class I need to work on. Scrolling at anything smaller than about
> 30% magnification takes too long.
Ok, that's good to know. Would it help or hinder you if the groups became
tree-nodes with their contents as children?
> And while I'm on that subject, is there anything I can do to make
> scrolling at low maginfications faster? I realize I'm not running such a
> fast machine (900 MHz Via C3 w/ 256M), but Acrobat Reader on the same
> machine can really zoom around similar diagrams and the same is true of
> ERwin on my dual 350 MHz P-II, so it seems like it should be possible, at
> least in theory.
> I keep meaning to really investigate scrolling performance with gprof
> (any recommendations other than gprof?), but haven't gotten to it yet.
If this is with 0.91, then most likely text rendering is to blame.
Especially when using AA, it has taken a performance hit, I think there
are some caching opportunities we're missing so far.
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| HĂ„rdgrim of Numenor
"I do not agree with a word that you say, but I |----------------------------
will defend to the death your right to say it." | Where are we going, and
--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?