RFC: Kate Part + fixed / non-fixed fonts

[Christoph Cullmann]

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
- textWidth() stuff (katedocument too), where we use the widths of each char 
to calc the real width of the string
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 
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).

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) ?

>
> > 2. would there be some other probs I don't thought of ?
>
> See above.
>
> Lars

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