Subject: Re: commit - fix bug 1385 <+backend rant>
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sun Apr 29 2001 - 10:44:21 CDT
On Sat, 28 Apr 2001, David Chart wrote:
> --On 28/4/01 0:21 +0100 rms@greymalkin.yi.org wrote:
>
> > I consider 1.0 should be postponed *at least* until the backend improves.
>
> I'm inclined to agree. From the user's perspective, constantly sluggish
> performance is a worse problem than an occasional crash. I can work around
> a program that predictably crashes under certain circumstances (and do). I
> can't work around a program which feels slower on a 400MHz iMac than Word 6
> felt on a Power Mac 7200/75 -- and Word 6 was notoriously slow on the Mac.
>
Yes I agree too. However once I'm done implementing all the features I
want I'll turn my attention to this if it hasn't already been solved.
There is LOTS of room for improving our drawing performance. We draw each
character 3 TIMES upon a key press and redraw the entire screen whenever
we scroll.
The oldest bug on our book (BUG 119) is another symptom of this. I assert
that that slow re-redraw can be cured by drawing drawing everything to an
off-screen bixbuf (as well as the screen) then upon an expose event (which
carries a clip mask of the area with the expose) we simply flush the
relevant part of the offscreen pixbuf to the screen. gdk has routines to
do this. See Havoc's book and the code from gnome-canvas and Dia for hints
on how it's done.
I believe we can also use this technique to massively increase our
scrolling perforance by flushing this pixbuf to screen as well
(appropriately offset of course.)
GTK hackers are encouraged to investigate these ideas. See the code in
src/af/xap/unix/xap_UnixApp.cpp (for how we handle expose events) and
src/af/gr/unix/gr_UnixGraphics.cpp will require modifications to save and
flush these buffers to screen.
This double buffering will be provided automatically by default for gtk
V2.0. However I don't think we should require gtk V2.0 for Abiword 1.0
even if the release dates are approximately the same.
For the 3 draws per keypress we need to make a careful study of what
exactly is happening and see if we can reduce these redraws to 1 on
average. I think we can.
I'm 100% sure we can greatly improve Abi performance on Unix.
Cheers
Martin
This archive was generated by hypermail 2b25 : Sun Apr 29 2001 - 10:44:46 CDT