Re: X11 scroll-wheel improvements

[Fred Kiefer]

On 17.01.2012 00:08, Eric Wasylishen wrote:
> On 2012-01-16, at 3:29 AM, Fred Kiefer wrote:
> > On 16.01.2012 09:43, Eric Wasylishen wrote:
> > > Hey, I just made two commits to gnustep-back (r34553 and r34554)
> > > which make a big improvement to scrolling with a mouse
> > > scrollwheel or trackpad's scrolling feature.
> > >
> > > The first helps avoid the GSDisplayServer event queue from
> > > filling up which prevents window autodisplay, and the second
> > > implements coalescing for scroll events. The coalescing seems to
> > > work very nicely - it means that the rate of scroll events sent
> > > to gui depends on how quickly gui can deal with them. As a
> > > result, scrolling with the scroll wheel feels just about as
> > > responsive as grabbing and moving the scroll bar.
> > >
> > > Let me know if it also works well for you, or you have any
> > > problems. :-)

> > If we should not listen for events in NSConnectionReplyMode, we
> > need a similar change for the Windows backend as well. But wont
> > this lead to an application that might be unable to participate in
> > a Drag&Drop interaction? Or anything else that requires a mixture
> > of X events and DO?
>
> I'm not sure… I don't have a great understanding of run loops. It
> doesn't seem to have broken drag&  drop.
>
> My understanding is that NSConnectionReplyMode is a run loop mode
> only used for private run loops created by NSConnection for
> synchronous method calls. If that is a correct interpretation than I
> think "not listening for X events in NSConnectionReplyMode" makes
> sense.

D&D was just an example here (and the pasteboard tool, gpbs, would have 
been a better one). What I was thinking of where applications that 
communicate via DO and one of them also needs to handle X events to do 
its job. When we ignore X events while in a DO connection this might 
lead to a deadlock as that application wont respond. At least it was 
something like that that lead to this mode being included here a long 
time ago. But this reasoning may now be incorrect. I just don't see it 
at the moment. And it is all to easy to remove something that isn't 
needed in your current test application, but required by some code out 
there.

> > In you checkin comment you state "In the long run I think we should
> > get rid of the AppKit event queue". What benefit do we get from
> > only getting one event at a time from the X event queue?
>
> The problem is, the run loop doesn't run until the GSDisplayServer
> queue is empty (see -[GSDisplayServer getEventMatchingMask:…]) so you
> end up with bugs like prior to r34553, you can prevent the Ink window
> from autodisplaying by continuously rotating the scroll wheel.
>
> In other words, if there are 3 events in the GSDisplayServer queue,
> the main loop in -[NSApplication run] will run for 3 iterations
> without running the NSRunLoop, and hence no performers fire, and
> window autodisplay won't happen.
>
> This was the motivation r34553, it only adds one event at a time to
> the GSDisplayServer queue.
>
> For visualizing the queue size you can add this: if ([event_queue
> count]>  1) { NSLog(@"--queue has>1 ( %d ) objects. last: %@",
> (int)[event_queue count], [event_queue objectAtIndex: [event_queue
> count] - 1]); } to the start of the do/while loop in
> -[GSDisplayServer getEventMatchingMask:…].

That is the point to reflect on the whole event queue mechanism. I am 
not saying we are currently doing things right, but we should rather 
look for the flaw in the implementation then to throw it all away. The 
event queue itself is actually an optimisation idea. The basic idea here 
is that event handling is more important than drawing. This is true as 
there is no point in drawing something that was already obsoleted by 
another event. But it may be that we are implementing/using it 
incorrectly. So the question should rather be, why don't we get the 
events handled fast enough to have an empty event queue most of the time?
One obvious reason is our slow text layout code. But even that should be 
easily handled by a fast computer. We really need to do some 
measurements to find out why events are left unhandled. I hope to find 
time for that later today.

> > We would also loose the ability to post events into the queue from
> > code. Or would you want to generate an X event from the NSEvent and
> > put that in the X queue?
>
> > A separate queue allows us to generate multiple events from one X
> > event, or as seen in your scrollwheel code, to compress events.
> >
> > I think that these changes are wrong and that we rather should try
> > to find out how to better manage our event queue to get the
> > benefits from it.
>
> Well, maybe the suggestion to get rid of the GSDisplayServer queue is
> not a good idea.

Looks like we agree here.

> I think r34553 is sensible, though, and it
> eliminates the bug I mentioned in Ink.

I believe that it eliminates the redrawing bug, but does it do so in the 
right way? Some time ago somebody rewrote most of the mouse down 
handling code to have a very tight inner loop that polls for mouse 
events. It may well be that one of these optimisations is the cause of 
the problem. We may need rearrange the way we manage run loop modes. For 
example, which ones we use for drawing.