On Thu, 2005-05-12 at 18:05, Angus Leeming wrote:
...
> > What is making it slower?
> > Is it the screen drawing or the new two-stage drawing thing?
>
> In 1.3 we have a row cache and redraw only those rows that have changed.
> In 1.4 we redraw the entire document on every single key press. If the row
> is 'on screen' then the real painter is called. If not, then the painting
> is performed by the null painter.
>
> RowPainter.C:
>
> void paintPar
> (PainterInfo & pi, LyXText const & text, pit_type pit, int x, int
> y)
> {
> // lyxerr << " paintPar: pit: " << pit << " at y: " << y << endl;
> static NullPainter nop;
> static PainterInfo nullpi(pi.base.bv, nop);
> int const ww = pi.base.bv->workHeight();
>
> Paragraph & par = text.paragraphs()[pit];
>
> RowList::const_iterator const rb = par.rows().begin();
> RowList::const_iterator const re = par.rows().end();
> theCoords.parPos()[&text][pit] = Point(x, y);
>
> y -= rb->ascent();
> for (RowList::const_iterator rit = rb; rit != re; ++rit) {
> y += rit->ascent();
> bool const inside = (y + rit->descent() >= 0
> && y - rit->ascent() < ww);
> RowPainter rp(inside ? pi : nullpi, text, pit, *rit, x, y);
>
> y += rit->descent();
> rp.paintAppendix();
> rp.paintDepthBar();
> rp.paintChangeBar();
> if (rit == rb)
> rp.paintFirst();
> if (rit + 1 == re)
> rp.paintLast();
> rp.paintText();
> }
> }Yes... and in the end, what gets called is pain_.text(...), which for the null painter just returns without doing anything, like any other paint operation. I understand that the number of such calls amounts roughly to the number of same-font substrings in the document, right? That's what this comment 271 // collect as much similar chars as we can seems to imply. Does this amount of empty function calls really produce the slowness we are seeing? Or is it the "glue" inbetween? - Martin
signature.asc
Description: This is a digitally signed message part
