Re: X11 scroll-wheel improvements

[Fred Kiefer]

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.
> :-)

I definitely like the coalescing of scroll events (although this might 
mess up the order of events, was that intended?), but am unsure about 
the other change.

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?

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? 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.