Re: abi/src/wp/ap/win/ap_Win32Frame.cpp rev. 1.55


Subject: Re: abi/src/wp/ap/win/ap_Win32Frame.cpp rev. 1.55
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 07 2001 - 11:35:01 CST


At 04:52 PM 3/7/01 +0100, Mike Nordell wrote:
>Paul Rohr wrote:
>> I've been trying to figure out why our redraws on NT while scrolling are
>so
>> much worse than they used to be. I used to be able to cleanly do rapid
>> keyboard-level scrolling with the up and down arrows. Now it leaves lots
>of
>> artifacts on my P233 laptop.
>
>Wierd.AFAIK nothing I changed in that file should neither leave artifacts
>nor affect scrolling speed. I run a debug binary here and it works just
>fine. Have you tried it on that machine before (without changing gfx
>driver)? I'm just trying to find out if you have a bad gfx driver or if it's
>indeed an AbiWord problem that leaves these artifacts but somehow it doesn't
>show up on my machine.

This is the same machine I've been doing AbiWord development on since day
one, and the drivers haven't changed.

What I'm seeing looks like a race condition on events. The old drawing
logic worked fine, the new logic seems to have delays on the exposes or
something.

For example, when using the down arrow to scroll down through an
outline-like document with lots of single-line paragraphs of various
indentations, the old builds always scrolled smoothly. Now I get the
bottom-most line repeated up the screen as it scrolls up and the exposed
area isn't erased.

Speed isn't an issue -- I can sometimes get that line repeated for almost
the entire height of the screen before it catches up and get redrawn
properly.

Does that help, or do you need more of a description?

>Had I ever seen this behaviour I would have hunted it down.

That's what I figured. I'm on NT4, if that helps. Let me know what else
you'd like me to try.

>So _that's_ the reason they were stand-alone. I couldn't for my life
>understand why someone would have added scrollbars manually to a window.

Gotcha. I may be a slob occasionally, but one thing you'll learn about
Jeff's code is that he's very efficient and methodical. He rarely bothers
to design in functionality that he doesn't have concrete plans to use later.

For example, anyone who's been thoroughly infected with the emacs virus will
probably recognize his attempts to design edit methods so they could also be
used for hooking in scripting languages later. He may not have done enough
to support other kinds of complex object models (like DOM bindings to
ECMAScript, or the kinds of functionality exposed by various VBA dialects),
but emacs-like macros were *very* much on his mind.

>OK,
>with this knowledge it's obvious that those changes were bad. I'll see to
>it.

Thanks. :-)

Paul



This archive was generated by hypermail 2b25 : Wed Mar 07 2001 - 11:27:24 CST