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.

Reply via email to