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
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:
#
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?
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
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
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
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
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
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
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
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
&
This was the approach I took to made several demos while we were discussing
the new data model for Leo. This idea worked perfectly but not with the
current Leo data model. The main challenge is to have the list you have
described above (list of pairs (level, gnx)), always in sync with the Leo's
On Sunday, November 25, 2018 at 6:03:51 PM UTC-6, Edward K. Ream wrote:
4. In the first draft of this post, I said that detecting simple patterns
> on the line-oriented diffs will tell the redraw code what Leo did. But, as
> I write this I see (*huge aha*) that *the gui redraw code doesn't
I could try to explain how these idea came about, but they came so thick
and fast that it wouldn't be accurate. Recent work did contribute:
- Passing full and incremental redraw dicts from the Py to JS side.
I started thinking anew about the representation of positions.
- Trying to optimize
16 matches
Mail list logo
