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 <obj...@gmail.com> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev