[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: koffice/kword
From:       Reginald Stadlbauer <reggie () kde ! org>
Date:       1998-10-20 10:45:53
[Download RAW message or body]

Am Tue, 20 Oct 1998 schrieb weis@stud.uni-frankfurt.de: 
>Hi, 
> 
>On Mon, 19 Oct 1998, CVS by reggie wrote: 
> 
>> 
>> koffice/kword CHANGES,1.44,1.45 fc.cc,1.28,1.29 fc.h,1.15,1.16 
>>frame.cc,1.1,1.2 kword_page.cc,1.31,1.32 
>> Author: reggie 
>> CVSROOT: /home/kde 
>> Mon Oct 19 23:46:28 MET DST 1998 
>> Update of /home/kde/koffice/kword 
>> In directory zeus:/tmp/cvs-serv17562 
>> 
>> Modified Files: 
>>     CHANGES fc.cc fc.h frame.cc kword_page.cc 
>> Log Message: 
>> - Fixed lots of speed problems in KWFormatContext when editing long textes. 
>>t was terribly slow. 
>>   But it's possible that I introduced some bugs - if this is the case I'll, 
>>of course, fix them :-) 
>>   What I did: KWFormatContext::init(..) is called quite often when navigating 
>>with the cursor (e.g 
>>   a line up, deleting/inserting text, etc.). 
>>   The implementation of this init methode started at the first parag of the 
>>text and went through 
>>   _all_ paragraphs, until the needed one was reached. For long textes (I 
>>tested with 70 pages) this was 
>>   damn slow when you were nearly at the end of the text. Now init doesn't go 
>>through all parags anymore 
>>   if it is not really needed (and it is nearly never needed!). So this is 
>>much faster now. 
> 
>What do you do instead ? Cicero ( from which I took the original 
>word processor kernel ) cached FCs for every page start. 
>How did you do it ? 
 
This was not the case, every init started from the top of the document. Now I 
solved it that way: You can call the FC's init with a flag, if the calcs should 
start from the beginning of the page or not. If yes, it is doing it as before, 
if not, the pointer to the current parag is just set to the wanted paragraph and 
the values (ptY, frame, page, etc.) which are saved in the paragraph anyway 
(startPTY, startFrame, etc.) are used instead of calculation them from the 
beginning. This seems to work (fast), but I'll test it a bit more. 
 
Ciao, Reggie 
 
-- 
************************************* 
Reginald Stadlbauer 
Pfarrweg 8c, A-8010 Graz, 
Austria (Europe) 
 
E-Mail: reggie@kde.org 
 
Homepage: http://htualpha.tu-graz.ac.at/reggie 
 
Telematik Student an der TU-Graz 
EDV-Sachbearbeiter an der HTU-Graz 
KDE fan and developer :-) 
 
 

[prev in list] [next in list] [prev in thread] [next in thread]