Peter Kümmel wrote:
Helge Hafting wrote:
I checked out todays SVN, applied this patch, and compiled.
Unfortunately, it doesn't help. At least not on linux.
Scrolling a maximized userguide may still overshoot by several pages.
I'm running out of ideas...
Is this patch better (the flush call is new)?
Or with processEvents instead of flush?
I tried this patch too, and the problems persist.
How I test:
1. Open the user guide.
2. Scroll by holding down the mouse button inside the
scrollbar, so that it jump scrolls. This is the worst case.
Scrollbar arrows or keyboard scrolling isn't as bad.
I always get the same result. A small window does not
push the cpu to 100%, and then scrolling stops instantaneosly.
A full-screen window (1280x1024) push the cpu to 100% usage,
and then scrolling overshoots with many pages.
I have also tested a two-pc setup, one pc running LyX
and another running the xserver (showing the LyX window).
They were connected with an ADSL link.
There were some interesting results:
Driving the cpu to 100% on the xserver machine lead to the same
problems of overshooting. A large LyX window scrolling causes
this, or a small LyX window scrolling while the xserver
machine compiles something. This case was neither worse nor
better than running LyX locally.
A small LyX window scrolling on an otherwise idle xserver
has no problem. It is nice to see that LyX still performs nicely
with a networked display. The network overhead and latency
is apparently not part of this problem.
Driving the load to 100% by compiling on the machine running
LyX actually _helped_ somewhat. There was still overshooting
when using a large window, but not as much.
Looks like giving the LyX binary less time to run gave it
less opportunity to queue up extra scrolling for the future.
So the problems happen when LyX is working faster than
its display. :-/
A guess:
If you try to stop scrolling action as soon as there is a mouseup
event but it doesn't work - chances are you aren't getting the
event in time because the computer is so busy performing the scrolling.
Who nows - perhaps something as strange as a very short sleep
after each scrolljump could help with this? Unless someone knows a better
way? Sleeping to solve performance problems seems weird, but it might
provide enough time for the mouseup event to get delivered?
Helge Hafting
