RFC: Kate Part + fixed / non-fixed fonts

[Lars Knoll]

> 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.

> 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