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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
