Re: A question on discardEventsMatchingMask:beforeEvent:

[Dr. H. Nikolaus Schaller]

Am 29.01.2011 um 15:13 schrieb Fred Kiefer:

> Am 28.01.2011 15:53, schrieb Banlu Kemiyatorn:
>> On Fri, Jan 28, 2011 at 5:39 PM, Banlu Kemiyatorn <address@hidden> wrote:
>> 
>>> (My NSApp has this implementation, allowing it to store parameters
>>> instead of real event on a fixed size loop queue which can migrate old
>>> event out of the fast loop queue and collect leak events and
>>> auto-scale the fast loop queue to serve dense event stream over time,
>>> I still need to bench a special NSEvent pool zone's thread locking
>>> deallocation against the traditional event generation, hopefully this
>>> evening, that would define the actual implementation of the design)
>> 
>> Just try benching with preallocated pool to make use of deallocated
>> object w/o reallocation, it's ~160% faster than traditional +alloc. So
>> my event queue would use a union for encapsulation, like XEvent.
> 
> Not using alloc/free always gives you a big benefit. The question is how
> this pays out in over all memory usage.
> I always wanted to use pools for a few other highly used fixed siue
> object types in GNUstep, but never got around to it. My favourite at
> that time was NSAffineTransform, but using our memory debugging facility
> (Click on the icon in the about window of an application) shows that
> even that class in rather low in the list of create temporary objects.
> (Although I had about 8 time more transforms than events creates)
> The objects that really would benefit from a pool are NSGDate,
> GSNotification and GSMutableArray. And even there this approach might be
> questionable, we first should find out, why so many of these objects get
> created and whether this is really needed. My feeling here is that the
> run loop is using objects on a too high level, where we could just work
> without them.
> As for the NSEvent class I don't see the big problem in creating and
> releasing the objects, but in having to handle all the duplicate mouse
> move events in an application. Before we even start to think about using

I have followed this discussion a little and wonder how many mouse movement
events really arrive per second. A mouse driver has a limited sample rate,
the kernel may throttle events and finally the X-Server can't deliver too
many similar events in a row through a low-bandwidth connection or
it would fail.

So is this really a problem to deliver *all* X mouse-moved events to the
NSApp?

BTW: I have removed any event merging logic from mySTEP since I
got bad results when drawing on a touchscreen into a NSBezierPath.
It produced unnecessary corners for fast moves...

On the other side I have seen no negative impact on any other application.

The only useful optimization is to check if the mouse coordinates have
changed by 1 pixel (but I think X11 does this anyway).

And another thought: is there any assumption that an NSApp can draw
about the maximum speed of events? Or must all NSApps be able
to handle to be flooded with events? I don't know and have never seen
such a statement.

So I suspect that event-merging in the backend is based on the (false)
assumption that Apps can safely assume a certain limit.

Just my 2ct,
Nikolaus