Richard Heck wrote:
Pavel Sanda wrote:
I'll try, but how do I do this? Is there some svn command for
reverting to a specific version?
i'm not aware of any direct revert command of svn.
however you can checkout particular revision of the svn tree
(i.e. the 18265 revision).
svn up -r VERSION
Thanks!
I did this, and recompiled. It did not help, the
resulting LyX still have that horrible lagging problem.
Further testing of the "good" LyX from may 8.
shows that it wasn't good enough either, perhaps a little better only.
I test with the userguide, and scrolling trouble varies a lot with location.
There are some places where the scrolling will stop immediately when I
release the button. And other places where it will roll for several
screenfuls.
Chapter 5 (math) is notoriously bad. Here even a short mouse press
in the scrollbar will cause several extra pages to scroll by.
(Don't use the little arrows on the scrollbar, press the mouse in the
larger jump-scroll area to get the bad effects.)
Using a load meter, I figured it out. Scrolling through parts with
"simple layout"
uses only a fraction of the CPU. In those cases, scrolling stops
instantaneously as I release the button.
Scrolling through parts with much math or other complications cause
scrolling to eat 100% cpu, and then the problems start with massive
overshooting. The test machine is a 2.4GHz pentium IV.
If your machine have spare cpu during scrolling, you won't see a problem.
Optimizations that makes drawing lighter helps, pessimizations
like 18266 makes the problem worse because I will reach 100% cpu
more often.
Nice drawing performance is always a good thing, I remember
xforms LyX _flying_ through the userguide on a 333MHz machine. :-/
But bad drawing performance isn't the real problem here. The real
problem is that LyX keeps scrolling after I released the button.
It is as if LyX is able to notice the button release on time when there
is some spare CPU, and struggles with noticing the release when
scrolling takes 100%cpu.
Is LyX (or qt) checking for "scroll timer expired" before processing
mouse events? Or is there some kind of shortcut in the scroll painting -
"if it already is time for doing more work, just do it and
don't bother checking pending events right now" ?
Just guessing here - but the problem makes LyX hard to use.
I can't use continous scrolling to get where I want, because it
will overshoot.
Even really bad drawing performance shouldn't cause this
overshooting. Bad drawing performance should merely
result in a slow LyX and 100% cpu usage.
To reproduce:
1. Maximize LyX on a high-resolution screen.
The more LyX need to draw, the easier it gets in trouble.
A very small window never have problems.
2.Go to chapter 5 (math) in the userguide, and try to jump scroll
down using the mouse. Release the button after a few seconds.
3. Run a load meter, to verify that you reach 100% cpu. If not,
consider starting background compiles or switching to a lower-
performance display driver such as svga/vesa. Use a 24-bit color
mode, that means more work. Testing on some old slow machine
might show the problem too. Or insert a simple delay loop in the
drawing code, to simulate slow drawing. "for (int i=100000; --i;);"
If you want to test linux version performance on a windows computer,
consider booting from a liveCD.
Helge Hafting
