On Sun, Oct 02, 2005 at 05:59:38PM +0300, Martin Vermeer wrote:
> On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre Poenitz wrote:
>
> ...
>
> > So we should try hard to pass through the critical path just once. I'll
> > send later today a preliminary patch that folds rowBreakPoint() and
> > setRowWidth(), i.e. reduces this by a factor of two and gives an overall
> > gain of 8-12% when typing into a single long paragraph of about 1200
> > chars. I won't be able to take care of this patch after I send it to the
> > list, so I wouldn't mind if somebody took over.
>
> Looking at your later patch, am I right in assuming that this is
> orthogonal to the things that I have been playing with?
Yes.
The aim is the same: make it faster, but code is unrelated.
> > [Fine grained 'invalidation']
> > Does this sound like a plan?
>
> Yes... as it happens I was today thinking along similar lines. But
> wouldn't it be enough to just cache, e.g., the pos of row end, to
> determine whether the current row content changes or not, and if not,
> skip out of the rebreak and render routines? Or would that become messy?
I'd just record what happened and leave the interpretation of what needs
to be done to the actual update routine (the 'second phase'). So we have
a single point of failure when it comes to clever guessing and in that
second phase we have 'full information'.
How the information 'char was inserted' is stored is secondary. If
people feel recording line ends is enough - fine. I'd have started with
some struct { what, where, phase-of-moon }; or something as generic as
that.
Andre'
