On Fri, Mar 2, 2018 at 8:02 AM, vitalije <vitali...@gmail.com> wrote:
Also speaking about "rendering" tree and how it is expensive has always > seemed a bit strange to me, because I was expecting that rendering tree > items should do QTreeWidget by itself. I've always thought that this > vocabulary (rendering tree items) was caused by some ancient way the things > used to work perhaps in the Tkinter time or even before. > A very interesting question. Perhaps you have put your finger on a big blind spot on my part. As you say, the mind set may have come from Tkinter or Borland C++. I was surprised to see that Leo actually clears all items from the > QTreeWidget and then recreates those which are visible. It looked strange > to me > Now that you mention it, perhaps I've just be very stupid :-) > and I thought perhaps QTreeWidget can't handle very well large number of > items, so I made an experiment. > [snip] > It fills the tree widget with total of 10313 nodes (LeoPyRef.leo my > version) and tree seems very responsive. There is no sign of performance > issues. Expanding and collapsing nodes is smooth. > > This left me wandering. Why Leo doesn't use this widget as it is, and just > dump all the vnodes to it? Is there something I am not aware of? > A superb question. I don't know the answer. As Terry says, there may minor issues with icons or hoisting, but that's probably a nit. Performance gains are always very welcome, provided that somehow Leo works exactly as it did before. Without looking at your demo code, I infer that you believe this is possible. Without remember anything about dawn of Leo's Qt tree, I suspect that I was lead astray by history. A more native implementation is worth serious consideration. > The only thing that I don't understand is why are we deleting all the items on every redraw and then creating new ones. instead. That seems to me wrong and most probably is the cause for the delay in tree actions. I have no idea why I did things this way. Perhaps I just wanted to simplify some code that is, in fact, not needed at all. In essence, this is an important lifetime question. Perhaps I thought that killing everything on every redraw was somehow simpler than figuring out what tree items are still valid. Or something like that. I do know that the code to maintain references is fairly complicated, requiring several dicts. Perhaps in your proposed scheme those complications can go away. There is one more thing to consider, just for completeness. Mouse action on the tree must generate the expected events so that Leo changes nodes correctly. But I suspect you know that :-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
