Subject: Re: Commit: rework edit methods
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Sat Feb 10 2001 - 18:12:00 CST
Martin wrote:
> This is all good stuff but to me the biggest "slowness" issues
>are:
This is good. Considering that each time you press any arrow key, an edit
method gets called and then mapped to a function and *then* translated into
a GR_Graphics call and then mapped onto a GTK or MFC or whatever call, it
makes sense to speed up the ap_EditMethods layer too.
>For 1.
>
>Having used Abi in Windows I can attest that scrolling is MUCH faster
>there. I *think* this means that the gtk version of abi should use a
>double buffered gdk. So we draw to off-screen memory then dump that to the
>screen. That way we save several round trips to the Xserver. We also have
>to see if there is some way we don't have to draw the same line 3 times in
>order to avoid character dirt.
Double buffering makes lots of sense. I'll look into this for
GR_UnixGraphics. GnomeCanvas does this nicely, for example.
>For 2.
>This is really slow because Abi honours every expose event and redraws the
>entire screen every time any part of it is uncovered. We can speed this up
>enormously by dropping all but the last expose event in the gdk queue.
>This would also be speed up with the double buffering I mentioned for 1.
Yes, double buffering would speed things up here and so would dropping
expose events. GnomeCanvas also does this nicely.
>For 3.
>This is a matter of synchronizing the scroll events with expose events
>redrawing. Abi should not scroll until an expose event redraw is
>completed.
This is also a good idea, but might be a little harder to implement.
I'll look into reworking parts of the GR_UnixGraphics class.
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Sat Feb 10 2001 - 18:12:04 CST