Scrollbar auto-repeats at very high speed after very short delay

[lgt@…]

Clicking in the scrollbar trough to scroll through a document auto-repeats after
a short delay, as expected. However, the delay before auti-repeating kicks in is
too short and the repeat rate much to fast on my system. Most of the time I
cannot use clicking in the scrollbar trough to page forward in my documents
because the delay before auto-repeating is shorter than my single-click time
(and I'm not a slow mouser...)

The problem is ALSO present in various value-setting widgets in (eg) the
Preferences dialogues. Trying to change the DPI settings from the "Preferences
-> Screen Fonbts" page by clicking on the little arrow buttons results in the
value displayed clocking up (or down) madly.

I guess this is /probably/ an Xforms-and-LyX issue, but I'm not familiar enough
with the code to find out. I do have other Xforms applications, and they *don't*
have the same problem (repeat delay and rate are quite reasonable).

Relevant system info:

RedHat Linux 7.3
Dual PIII-550 (SMP) system
LyX 1.2.1
XForms 0.89
XFree86 4.2.0

To reproduce problem:

1) Open a long document (eg "Help -> User's Guide")

Scroll window by clicking in lower scrollbar trough area
Vary click dwell time to see when repeat sets in and how fast it is

2) Select "Preferences -> Screen Fonts"

Try to adjust "Screen DPI" setting using left & right arrow buttons.
Vary dwell time as above.

[leeming]

I have certainly seen something similar in the past, but can only say that,
with xforms 1.0RC6.1, all is well in this regard. Does upgrading fix the
problem?

[levon]

Nope, I'm running latest xforms and scrolling (e.g. when selecting)
is unusable. The prefs things are also a little too fast but that's a different
bug.

[leeming]

and that's the one (the prefs counter) I was alluding to. Apologies for not
making that clear. The scrolling when selecting is definitely a bug. It's also
our bug, not xforms', so upgrading won't help with that.

[lgt@…]

Just to clarify something: The problem as I am seeing it was *not* "scrolling
while selecting", but "scrolling by clicking in the scrollbar trough".

I have just tried scrolling while selecting on my system, and indeed that is
*also* unusable, but the problem I see is not dependent on selecting being in
progress.

I just wanted to make that clear, in case it changes the diagnosis of the problem.

[leeming]

I've had a look at the code and it would appear that

• left mouse button: increment size = "1 page"
• right mouse button: increment size = "1 line"

So, the short term solution is to use your RMB, not your LMB. I'll suggest
changing this around on the LyX developers list (as I find it counter
intuitive too).

Now, I realise that that isn't exactly what you'd like, but to do more than
this, client code (here LyX) would have to be able to distinguish between a
callback from the scrollbar trough and the scrollbar slider.

Now, I realise that you are effectively suggesting the following behaviour:

• For the slider, a mouse event is to be processed immediately by going to

that line in the document.

• For the trough, we'd like "increment 1 line/1 page" per processed mouse

event together with a "reasonable delay" between increments.

In principle, this is easy enough, but to do so the client code (here LyX)
would have to be able to distinguish between a callback from the scrollbar
trough and the scrollbar slider. Unfortunately for us, xforms hides this
information and tells us only that "an event has occurred somewhere in the
scrollbar".

I'll ask on the xforms list, but don't hold your breath.
Regards,
Angus

[lgt@…]

Xforms scrollbar demo (slightly modified)

[lgt@…]

You shouldn't have to do this yourself! The client program should only need to
know when an update is necessary, not how the user clicked on the scrollbar.
This functionality is properly the domain of the Xforms scrollbar widget, and
indeed it *does* provide exactly this behaviour. As long as
fl_set_scrollbar_increment has been called with appropriate values (which LyX
cetrainly does do), everything works correctly - the dragging, clicking,
repeating etc. all work as expected of a scrollbar and the delay and repeat
rates are 'reasonable'.

Except with LyX. Something in LyX seems to be interacting badly with the xforms
events and causing the speedup. I've looked at some of the LyX source in this
area of the interface and haven't been able to spot the problem yet. I'll keep
looking when I have time (unfortunately very busy at the moment). Meanwhile,
I've attached a modified version of one of the xforms demo programs
(scrollbar.c), to show that xforms really does do this itself. I merged the
three source files into one and added calls to fl_set_scrollbar_increment,
otherwise it is as distributed in xforms version 1.0 RC5.2 (I hevn't tried RC
6.1 yet). Compile & link this agains xforms and play with the scrollbar buttons
& troughs.

[leeming]

Without wishing to be rude, this is incorrect. A single mouse should increment
us by one page. This is what happens and is what fl_set_scrollbar_increment
returns. Pressing the mouse in the trough however results in multiple mouse
events being passed to LyX. We are saying that if two events come too closely
together, then we should filter out the extra ones.

[lgt@…]

After a lot of code searching, I think I finally know what the problem is, and
why my other xforms apps (including the demo program I attached) work as
expected when LyX doesn't.

There are two ways to get xforms to do its stuff: fl_do_forms(), which enters a
loop and (usually) doesn't return, and fl_check_forms() which does one pass of
updating the interface, polling events etc. and then returns to the main
program. LyX uses fl_check_forms() while all the other xforms apps I've tested
use fl_do_forms().

Crucially, in the depths of the xforms library code, there is a polling wait for
async I/O (using select() I think). The timeout for this operation is delta_msec
in the case of fl_do_forms(), which has a value of 50 ms (40 ms if idle
callbacks are used). However, fl_check_forms() calls the underlying code
differently, resulting in a timeout of SHORT_PAUSE msec. SHORT_PAUSE is #defined
as being 10. So if fl_check_forms() is called in a tight loop (as LyX ends up
doing in frontends/xforms/GUIRunTime.C routine GUIRunTime::runTime()) the upshot
is that everything is called about 5 times as fast as with fl_do_forms().

This, as far as I understand it, exactly accounts for the behaviour I'm seeing.
I modified the little shrollbar test program to have 'while(1) {
fl_check_forms(); }' instead of 'fl_do_forms();' and sure enough - everything
scrolls very fast. :-)

As for what to do about it: I'm not sure. It's really an xforms issue I think,
as it shouldn't depend on the frequency of polling to set the delay and repeat
rate for scrolling (or any other user interaction feature). The faster your
processor, the faster it scrolls!

A crude LyX workaround would be to replace fl_check_forms with fl_do_forms or to
insert a fixed delay in the loop, but this is obviously a bad hack and would
probably impact badly on the responsiveness of LyX.

[leeming]

mail sent to the xforms list

[leeming]

Good hunting! However, we aren't in the business of crude work-arounds and I
think that I know the "real" fix to the xforms source. I've just sent my
findings/suggested way forward to the xforms list. I'll append it here...

[leeming]

simple but "correct" patch to the xforms source

[levon]

What happened wrt xforms list ?

[abraunst]

can this be closed already?

[leeming]

This bug has been fixed in XForms 1.1cvs.