latencies in scrolling

[GoogleCodeExporter]

Hello and thanks for MacVim. It has totally replaced gVim here.

When I try to scroll the text, MacVim sometimes takes significant latencies
to respond (up to more than half a second), and it sometimes ignore the
scrolling at all, at least in parts. This is unlikely to be due to lack of
resources as this also happens on my Mac Pro.

I have tried to remove all the plugins (temporarily removed the ~/.vim
directory) but this does not change the behaviour. I observe this more
frequently when a new buffer is opened, and to a lesser extent when the 
MacVim window gets the focus.

I observed this on all recent versions of MacVim (I'm running 7.1 32 now),
on OS X Leopard 10.5.3 on a Mac Pro (4 cpus, 2 GB ram), with the attached
.vimrc file.

Original issue reported on code.google.com by m...@bitchx.it on 25 Jun 2008 at 12:49

Attachments:

• vimrc.txt

[GoogleCodeExporter]

Which filetypes do you see this most often with? Ruby files?

Original comment by nicotha...@gmail.com on 25 Jun 2008 at 2:17

[GoogleCodeExporter]

99% I use MacVim for source code, this includes .tex files and .c / .cpp files. 
I
don't observe noticeable differences with them wrt the type. I never tried with 
ruby
files but I can do if necessary.

Original comment by m...@bitchx.it on 25 Jun 2008 at 3:06

[GoogleCodeExporter]

How many MacVim windows are open? Which size are they (i.e. output of `:set
columns?`, `:set lines?`)?

Original comment by nicotha...@gmail.com on 25 Jun 2008 at 3:27

[GoogleCodeExporter]

happens with the same frequency also with 1 window, 1 tab. 
columns=144
lines=58

Original comment by m...@bitchx.it on 25 Jun 2008 at 4:37

[GoogleCodeExporter]

With the window filling the entire screen I get columns=180 and lines=53 and I 
see no latency problems so I 
guess its not directly related to window dimensions.  Are you saying this only 
happens after using MacVim for 
a while (if so, how long?) or does it happen as soon as you start the 
application?  Does it happen every time 
you edit a file?

I don't understand what you mean when you say "I observe this more
frequently when a new buffer is opened, and to a lesser extent when the 
MacVim window gets the focus."  Could you please elaborate?

If you have the time, could you download an older snapshot to see when this 
problem was introduced?  (Go to 
the "Downloads" tab on the MacVim project page and search "All Downloads" for 
"snapshot" to see older 
snapshots.)

Original comment by bjorn.winckler@gmail.com on 25 Jun 2008 at 9:11

[GoogleCodeExporter]

it may sound ridiculous, but I have noticed this only happens with apple's 
Mighty
mouse and the laptop trackpad. May this be related to resolution? I my logitech
mouse, this is significantly coarser.

Your questions:
1) happens more when MV just started
2) also happens when MV was in background, then gets the focus
3) it lasts for few seconds (2-3) then it becomes responsive again, then never
reappears unless you do 2) again
4) it happened in earlier releases (I began to use MV 2 months ago circa)

Original comment by m...@bitchx.it on 28 Jun 2008 at 10:13

[GoogleCodeExporter]

Thanks for reporting this problem but unfortunately I can't begin to guess what 
is happening and I can't do much 
until I can recreate the problem myself.  If you are a developer maybe you 
could try looking into it yourself?  (If 
so, I can give you pointers as to where to start looking.)

Original comment by bjorn.winckler@gmail.com on 1 Jul 2008 at 7:24

[GoogleCodeExporter]

Hi bjorn,

Unfortunately I have no expertise with ObjC. E.g. Who takes care of calling that
setScrollbarPosition() ?
I'm convinced that the problem is the excess of resolution, so think the way to 
go is
to "soften" the burst of "scroll" events to vim. E.g., when a "scroll" event 
occurs, do:
1) increment a static counter of such events
2) set a timer of eg 50ms
3) when the timer expires, move in one step to a position computed taking into
account the number of steps of the wheel. Then reset the counter.

although high-level, this solution is simple and self-adaptable to the mouse
resolution (through the timer).

Original comment by m...@bitchx.it on 8 Aug 2008 at 4:55

[GoogleCodeExporter]

Ok, now I understand the problem.  It is almost certainly that too many 
"scroll" events are sent in quick 
succession.

I will need your cooperation to fix this though since I cannot reproduce over 
here.  Before I start working on 
this, I need to know if you would be able to apply patches and build MacVim on 
your own?  If so, I would write 
a patch, send it over to you and let you test it and then give me feedback as 
soon as you can.  Are you 
able/willing to do so? 

Of course, and this is something I would prefer, I can instead give you 
detailed clues where to start looking 
and you could try writing a patch yourself.  (If you know C and some object 
oriented programming then it is 
quite easy to pick up Objective-C.)

Let me know what works for you and I'm sure we can fix this bug.

Original comment by bjorn.winckler@gmail.com on 8 Aug 2008 at 6:26

[GoogleCodeExporter]

Bjorn,

Unfortunately my bottleneck is not willingness but time :)
I prefer to go the first way (you patch, I build and report). Feel free to ask 
me
whatever you need to know.

Original comment by m...@bitchx.it on 9 Aug 2008 at 9:24

[GoogleCodeExporter]

Is the problem only apparent using a scroll wheel or does it happen when you 
drag the scrollbar as well?

Original comment by bjorn.winckler@gmail.com on 15 Aug 2008 at 5:49

[GoogleCodeExporter]

The scrollbar always worked fine.
When the wheel takes more than a couple of attempts to scroll, I grab the 
scrollbar
to move.

Original comment by m...@bitchx.it on 15 Aug 2008 at 6:22

[GoogleCodeExporter]

Good to know.  I can focus on the scroll wheel code then.

Original comment by bjorn.winckler@gmail.com on 15 Aug 2008 at 6:26

[GoogleCodeExporter]

Here is a patch to try out.  Make sure you git-pull before trying to apply.  To 
apply, use the git-am command, 
e.g.

git-am ~/Desktop/0001-Limit-scroll-wheel-message-frequency.patch

(If you put the patch on your Desktop.)

Let me know how it goes.  The update frequency is currently limited to ~30 Hz 
which may be too high but I 
won't be able to tell until you try. :-)

Original comment by bjorn.winckler@gmail.com on 15 Aug 2008 at 7:40

Attachments:

• 0001-Limit-scroll-wheel-message-frequency.patch

[GoogleCodeExporter]

I have tried the patch on a Macbook Pro scrolling on the embedded touchpad. That
doesn't have the resolution of the Mighty Mouse but it's definitely higher than 
a
normal mouse wheel. It used to give a similar problem, but with smaller delays.
In this context, the patch fixes the problem. MacVim is responsive and there is 
not
the feeling that the scrolling is less smooth.
I will try the same patch tomorrow with the Mighty Mouse and update the report. 
I
have the impression that a rate of 20Hz would be more than enough anyway.

Original comment by m...@bitchx.it on 15 Aug 2008 at 8:29

[GoogleCodeExporter]

Great!  To test your theory about 20 Hz being enough you could simply replace 
all occurences of "0.03" (there are 
two of them) with "0.05" in the patch (I'd be interested to know the result).  
If everything works tomorrow with 
the mighty mouse I'll merge the patch so that it gets included in the next 
snapshot.

Original comment by bjorn.winckler@gmail.com on 15 Aug 2008 at 8:48

[GoogleCodeExporter]

The patch mitigates the problem with the Mighty Mouse too. The problem is not
resolved totally, but occurs with way lower frequency and it lasts for way 
shorter.
Although it is perceivable, I don't think it affects the usability of MacVim 
anymore.

Changing the frequency from .03 to .05 and up to 0.08 doesn't have a perceivable
effect. I have the impression that 0.05 shortens the "stuck time", but I cannot 
get
any objective comparison. I left 0.08 in my build as final choice.

thanks for the patch

Original comment by m...@bitchx.it on 16 Aug 2008 at 11:34

[GoogleCodeExporter]

It's a bit strange that it does not completely resolve the problem...maybe 
there is something else going on as 
well, but at least it is better with the patch than without so I'll merge it 
and include it in the next snapshot.  After 
some experimenting on my machine I settled for 20 Hz but we can always change 
this in the future if it is too 
high.

Thanks for the assist!

Original comment by bjorn.winckler@gmail.com on 16 Aug 2008 at 12:33

• Changed state: Fixed