RFC: Kate Part + fixed / non-fixed fonts

[Christoph Cullmann]

On Wednesday 10 April 2002 10:30, Lars Knoll wrote:
> > On Tuesday 09 April 2002 19:26, Lars Knoll wrote:
> > > > Hi,
> > > > kate seem to have some speed probs, due of "lame" redraw at the
> > > > moment. My plan to improve the whole drawing / calculation stuff
> > > > would be to drop the support for non-fixed fonts, or at least enforce
> > > > them to behave like "fixed" ones. (Which would make the most
> > > > text-width, cursor-pos, view-pos, ... calculations VERY fast + easy)
> > >
> > > Well, if you want BiDi support, it won't be that easy after all, so I
> > > don't know how much you would gain from it. A maybe better way to speed
> > > things up is to cache text width of chars. I don't know what you're
> > > doing, but qrichtext can handle large amounts of text reasonable fast,
> > > so it should be possible in kate aswell. Did you once try profiling to
> > > pin down the problems?
> >
> > Should compile kate with profiling, but my first thoughts (where the
> > speed probs should be settled) are:
> > - paintTextLine function of katedocument, as it seems not to be very
> > clever with painting the QString
>
> Looking at the code, that's probably true. See also below.
>
> > - textWidth() stuff (katedocument too), where we use the widths of each
> > char to calc the real width of the string
>
> The problem here might be that you do this calculation during painting.
> That's something most other editors cache, at least for the visible region.
>
> > Perhaps I am totally wrong here, but have at the mom no time for heavy
> > profiling (and not very used to do it ;)
> >
> > > > But before I go to do that, I first want to get some feedback about
> > > > the idea, in the areas:
> > > >
> > > > 1. would that kill any unicode support in the future ?
> > >
> > > Not necessarily, but I would personally hate it as I don't like fixed
> > > fonts in anything else than a terminal.
> >
> > I don't really like them, too. But on the other side:
> > each other "fast" editor under unix/x11 uses fixed width fonts too (mosty
> > because the come from the terminal, like vim, nedit, (x)emacs), and
> > kate's
>
> xemacs works just fine with variable width fonts. qrichtext does. khtml
> manages to get reasonable repaint speed for all but some pathological web
> pages, so it must be possible for kate aswell without dropping support for
> proportional fonts.
>
> > biggest problem at the moment is speed, which would be better with them.
> > If the speed problem could be solved with better caching of widths or a
> > smarter way of handling the painting, would be fine, too. But at the
> > moment I see no really better thingy for painting than the current one
> > (which is not the great super thing, but works).
>
> It might be just introducing a little bit of caching here and there, maybe
> inlining one or two methods (as the getAttr() call) that's needed. You call
> eg. lineColSelected() a few times for the same chars in the whole painting
> routing. Caching these values in some local variables might aswell help.
>
> Another point is to try to avoid to calling fontmetrics::width() three
> times for the same strings. That can be easily done by moving the
> background painting into the same loop as the string painting.
>
> More ideas: Inline the attribute() call, and avoid calling setFont()/setPen
> everytime, but only if the Attribute or color changed. I would guess that
> could already give you quite a bit of speed improvement.
Sounds like good points, hope to get the time to take a deeper look and 
rewrite some of this stuff ;) Hopefully that will bring us back to some more 
speed again.

>
> > My next prob:
> > How to handle block selection "right" with variable width fonts ? Seems
> > to be very impossible (and blockselection are a must for any better text
> > editor) ?
>
> What do you mean by block selection? The mode where you select a rectangle
> of text? That will probably only look nice with fixed fonts. With variable
> fonts, you could still select on columns, it might look a bit strange, but
> that's the users choice.
>
> Lars

-- 
Christoph "Crossfire" Cullmann
Kate/KDE developer
cullmann at kde.org
http://kate.kde.org