gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wrong order when process some events


From: Fred Kiefer
Subject: Re: Wrong order when process some events
Date: Tue, 27 Aug 2013 22:56:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

As nobody replied I just committed my hack. On my machines it gives
better results than the previous code. Please test whether this is true
for you as well.

Fred

On 26.08.2013 09:09, Fred Kiefer wrote:
> It may have seemed that there was no reaction to this mail but in truth
> I have tried to understand the issue at least once in the previous
> weeks. It just took me so long to come up with an idea. Last night I
> finally found something promising. This was only possible with this
> great example code that demonstrates the problem!
> 
> What I notices is that the method [NSWindow
> _checkCursorRectangles:forEvent:] that converts mouse move events in to
> NSCursorUpdate events goes through the list of views and detects both
> exit and enter events. In most cases this will find either an exit or an
> enter event, but sometimes the mouse moves directly from one tracking
> rectangle to another. Now if there is an exit and an entered event, the
> order in which they get detected is undefined. In that case it may
> happen that we produce first an mouse entered event and then an exited
> event. Which will basically leave the mouse cursor unchanged as we get a
> push followed by a pop. I think that what we should get is first a pop
> and then a push. Which means that we should go through the exit events
> first and then detect the enter events. Within the exit events the order
> isn't important, we just need the right count and within the enter
> events the order should be outer to inner, which is guaranteed by our
> code, as long as views don't overlap.
> A simple way to see that this corrects the issue is to hack line 3644 of
> NSWindow.m to post the enter event at the end of the queue. That way we
> always get the exit events before the enter events and the later will
> come in the correct order. This still is a hack, as we shouldn't post to
> the different ends of the queue, this could mess around horribly with
> what ever else is already in the event queue.
> 
> A proper solution could be to have a separate method to detect exit and
> enter events. But this could be a lot slower than the current code. Or
> we could send the exit events directly while posting the entered events
> to the front of the queue. (In which case they would again be in the
> wrong order the inner ones would come before the outer ones) Or we could
> get all the NSCursorUpdate from the queue, sort them, exits first, and
> process them in that order. But if there are two independent events the
> overall sort would result in the incorrect order. (If we put the events
> at the end of the queue)
> 
> Not sure, anybody with a better idea?
> 
> Fred
> 
> 
> 
> On 16.07.2013 08:18, Germán Arias wrote:
>> I suppose that all of you (or almost all) has been facing a cursor 
>> problem
>> with split views. When the split view contains a text view. Like in 
>> ProjectCenter,
>> where the browser and the editor are inside a split. Sometimes when you
>> move the mouse from the browser to the editor the cursor remains as
>> double arrow over the text view. This isn't a ProjectCenter problem.
>> Attached a simple test with three views. Each one with a diffrent 
>> cursor.
>> When you move the mouse from top to bottom, sometimes the cursor stuck.
>> This problem depend of the movement velocity. And maybe if you have a
>> fast computer, you will not see the problem. But at my computer this 
>> occurs
>> frequently. The problem here is that, sometimes, the view under the 
>> mouse
>> push its cursor, before that the previous view pop its cursor. The 
>> order  of
>> these events is wrong.
>>
>> I thought that this was because the NSWindow post the events at start 
>> of  the
>> event queue. And if the event posted previously has not been executed. 
>> So,
>> this would alter the expected order. But no, post the events at end is 
>> worse.
>>
>> Of course, a solution is increase the separation between views (or 
>> cursor
>> rects). But in splitview this is not possible. Any idea?
>>
>> Germán.
>>
>> <WrongCursor-0.1.tar.gz>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]