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

List:       koffice-devel
Subject:    Re: second attempt at redraw caching
From:       Jaymz Julian <jaymz () dspaudio ! com>
Date:       2002-08-11 3:15:35
[Download RAW message or body]


On Sat, 10 Aug 2002, David Faure wrote:

> More generally, drawParagString is a bit too lowlevel for this IMHO,
> it might concern only very few chars (when the formatting changes very
> often in a parag). Or too many (i.e. including the one that was just typed,
> so the text changed and the cache doesn't help at all for the current line!).

I agree that drawParagString is more low level than one would like for
this, however it is the *only* place where I was able to implent this and
actully have this work - My ideal solution would be (and hence was the
first thing attempted) to not call drawParagString at all for lines which
havn't changed/sections which havn't changed/whatever. 

This caused QT to do some incredibly bizzare things.  I spent several days
trying to work around QT doing incredibly bizzare things, and then I threw
my arms up and walked away from it, until I thought of doing it this way
instead.

(okay, i actully then avoided it for a day, because it's an ugly ugly
solution, but I got sick of hearing the people whinging "so, when are you
gonna have a koffice 1.2/kde3 based system for us to use?  when are you
gonna have a koffice 1.2/kde3 based system for us to use?  when are you
gonna have a koffice 1.2./kde3 based system to use?" :-p.  Someone really
should pay me to listen to that crap, lol)

> Another problem with the pixmap cache idea is that it means (yet another level
> of) double-buffering. Double-buffering breaks transparency (the stuff below the
> text will be overwritten with some bg color). [It also slows down printing, but it's a one
> liner to disable the cache stuff when printing (painter->device()->devType() != QInternal::Printer).]

QT is *supposed* to provide transparency to QPixmap's, no?  Okay, I
couldn't get that to work... i mentioned that re background colours in my
last mail, but it seems more important than i thoguht.  D'oh.

> The transparency issue is a bit more difficult to solve. The only way I see would
> be to "skip redrawing what hasn't changed" rather than "reusing a pixmap for the
> stuff that hasn't changed".

this would be generally ideal, not just for transparency reasons.  I just
was unable to make it go ^_^.

> Are you still testing this with the "very big paragraph (many lines)" case, or with
> normal-sized paragraphs? The question behind this is: would it help to skip redrawing
> the entire lines that haven't changed (it surely makes a BIG different in the case of
> a paragraph with many lines)?

I've always been testing with normal documents on the p5 based
systems... the "very big paragraph" exacmply was only created so that
other people could see the problem ^_^.  As I said at the time, I am aware
that's an artificial case.  (I imported a bunch of documents that we use
at computerbank into it, basicallty, and I have a paper document that I
type into it for testing purposes)

Basically, the speed problems on a p133 generally don't occour until the
second or third line.  at line #4 of any given parag, it's 10chars/update
without any patch, 1.5 chars/update with patches #1 and #3, and
4chars/update with patch #2 (due to patch #2 having a braindead cache
selection algorythm.  the one I sent last nght is much better at this
^_^).

the unpatched build, btw, was an optimized one, whereas teh patched builds
are debug builds littered with debug messages on eatrch char that I'm
generating.  So the 1.5chars/update, at that point, isn't sounding so bad
(it isn't bad to type on at that poiont).  It keeps this up for the
entire length of a normal sized parag, too.  

I never did try elephant.kwd on a p133, lol.

	- Jaymz

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]