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? > Now, suppose that even reducing the four calls to Paragraph:: > redoParagraph() to a single one is not enough. Together with my latest, it might just be, even on the Mac. > The singlepar machinery > won't help because a paragraph is the granularity there. So we'd need > something finer like a row. [This might be reasonable, as is most cases > after a single keystroke at most a single row is changed on screen.] > > For this to happen I'd think we should decouple the updating mechanism > from the actual structural changes by moving the actual redrawing into > a 'second phase' while the actual lfun handling only records what needs > to be done. > > I.e. when inserting a character somewhere we might just record 'inserted > at DocIteratorPos x'. More complex operations would just end up > recording several such items. In any case, the simple recording is not > expensive. > > Close to the end of the LFUN handling (or maybe just in the actual > paintEvent()) we could look at all recorded changes an make a fairly > educated guess on the absolut minimum required work. > > When e.g. inserting a single character, we could try to rebreak only the > row containing this characters. If still still yields only a single row > (i.e. the row was stretched enough to include the new character as well) > we are basically done - and we do not even have to redraw the whole > screen as we do currently, but just that single changed row. > > 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? - Martin
pgpVwJnFaKTKg.pgp
Description: PGP signature
