Hendrik Boom <[EMAIL PROTECTED]> writes:
> The account I am editing has something like 7000 or so transactions.
> Could this be relevant?
Yes. One way you can probably get substantial improvements in your
everyday work is to set the register to only show the past 200
transactions or so.
> - because gtk+ imposes a scrolling area limit af 32K pixels,
> you have too handle scrollong at a higher level in the protocol.
> - the higher layer is written in guile, which is interpreted (like Java)
> - so scrolling slows down quite a bit.
As Bill said, no guile in there.
> - deleteing a transaction involves recalculating sizes for the
> entire scroling area, and this also is done in guile, is
> interpreted, and so each deletion might end up taking the same
> order of magnitude of time as some of the analysis activities
> during importing.
Nope.
> - Events are queued, and not subsumed. So if you press the up cursor
> three times in a row, you end up displaying the register in three
> separate positions, instead of counting up-cursor presses and moving
> the register three lines all at once.
This may actually be part of the problem. ISTR that we've seen weird
behaviors with the gnome canvas and exposures (which are related to
scrolling) before. In those cases, I think it was acting as if it
wasn't doing any batching as you've described.
> P.S. For what it's worth, my processor is a Pentium running at 39.73
> BogoMIPS; 48 meg of RAM. I'm running SuSE Linux 6.3.
That's a nice test platform for slower systems. I'd like to see us
running well on systems near that speed if it doesn't force too many
compromises in the design. I suppose you can be our guinea pig :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
