On Monday, November 26, 2018 at 9:38:05 AM UTC-6, Edward K. Ream wrote:
app.make_redraw_dict: 5 direct children 0.058 sec.
> app.flatten_outline: 2813 entries 0.016 sec.
>
> On to diffing!
>
It's been quite a day.
app.make_redraw_list now uses diff to create a list of opcodes, and passes
that l
On Monday, November 26, 2018 at 9:02:17 AM UTC-6, Edward K. Ream wrote:
app.make_redraw_instruction_list should be roughly as fast as
> app.make_redraw_dict. It's next.
>
"make_redraw_instruction_list" is the wrong name. The intermediate step is
to flatten the outline to make it diffable. The
On Monday, November 26, 2018 at 6:41:09 AM UTC-6, Edward K. Ream wrote:
I'm going on about [the speed of of app.make_redraw_dict] because this is a
> crucial figure of merit, which depends on the number of visible nodes.
>
For timing, app.redraw now contains:
ap = self.p_to_ap(p)
if 1:
# F
On Mon, Nov 26, 2018 at 7:45 AM Terry Brown wrote:
> This may be true now, but perhaps Almar will be open to adding new
> > methods to the TreeWidget or TreeItem classes. Assuming that's
> > possible :-) And assuming a real performance gain would result.
>
> You can just subclass them?
>
Hmm.
On Mon, 26 Nov 2018 05:13:38 -0800 (PST)
"Edward K. Ream" wrote:
> This may be true now, but perhaps Almar will be open to adding new
> methods to the TreeWidget or TreeItem classes. Assuming that's
> possible :-) And assuming a real performance gain would result.
You can just subclass them?
C
This is an Engineering Notebook post. Feel free to ignore.
Here I shall discuss a vague feeling of unease I had about the redraw code
in leoflexx.py.
To state the nameless fear: In Leo's core, calls to c.selectPosition() and
c.redraw() happen *immediately*, but this is not true in leoflexx.py!
On Monday, November 26, 2018 at 6:59:37 AM UTC-6, Edward K. Ream wrote:
*Important*: it's not clear that the flx.TreeWidget or flx.TreeItem
> classes can actually take advantage of [the redraw instruction list].
>
This may be true now, but perhaps Almar will be open to adding new methods
to th
On Monday, November 26, 2018 at 6:30:20 AM UTC-6, Edward K. Ream wrote:
The Aha is that the redraw code *doesn't have to redraw all the visible
> nodes.*
>
[snip]
...the PY side will pass a *redraw instruction list* to the JS side. By
> definition, this instruction list specifies the minimum
On Mon, Nov 26, 2018 at 5:34 AM Edward K. Ream wrote:
> the test on p.level() is not necessary...[but] this doesn't change the
speed significantly.
...
> In any case, the time to compute this vital dict is 0.0004 sec. on my
machine.
Strange. Increasing the resolution of the timing sta
On Mon, Nov 26, 2018 at 6:02 AM vitalije wrote:
I don't know what is redraw_dict and where did it come from?
>
The redraw_dict is the dict that the PY side of leoflexx.py passes to the
JS side. This dict describes the entire screen to the JS side, so that the
JS side can completely redraw the s
I don't know what is redraw_dict and where did it come from? In this thread
you described a list of pairs (level, gnx).
So a snapshot might be a simple *linear* list of all *visible *positions:
> like this:
>
> level:gnx
> level:gnx
> ...
>
I know that computing this list on a large outline l
On Monday, November 26, 2018 at 5:21:10 AM UTC-6, Edward K. Ream wrote:
Happily, this can be improved, because it is already known that p is
> visible!
>
> if p.level() == 0 or p.v.isExpanded():
> children = [
> self.make_dict_for_position(child)
> for child in p.children(
On Mon, Nov 26, 2018 at 1:58 AM vitalije wrote:
This was the approach I took to made several demos while we were discussing
> the new data model for Leo.
>
Yes. I was aware of that. You could call this yet another factor that
primed my mental pump.
This idea worked perfectly but not with t
And yes, I fully agree with the title of this thread "Oh my: fast,
incremental redraws *are doable in any* gui", provided that the list of
pairs (level,gnx) is integral part of Leo's data model.
Vitalije
--
You received this message because you are subscribed to the Google Groups
"leo-editor"
14 matches
Mail list logo
