Hallo Herr Chisnall,
Hallo Frau Chisnall,
Hallo David,
Am Mon, 31 Jan 2011 09:59:10 +
schrieb David Chisnall :
> On 31 Jan 2011, at 09:51, SPUeNTRUP - Kai Henningsen wrote:
>
> >> When I was looking at it, I found it hard to see how best to make a fast
> >> allocation/deallocation scheme th
On 31 Jan 2011, at 09:51, SPUeNTRUP - Kai Henningsen wrote:
>> When I was looking at it, I found it hard to see how best to make a fast
>> allocation/deallocation scheme thread-safe.
>
> I learned this from ptmalloc3
ptmalloc() is very heavily optimised for the case in which malloc() and free(
Hallo Richard,
Am Fri, 28 Jan 2011 15:33:57 +
schrieb Richard Frith-Macdonald :
> When I was looking at it, I found it hard to see how best to make a fast
> allocation/deallocation scheme thread-safe.
I learned this from ptmalloc3. The comment explaining the central idea
is this:
/* arena_
On Sat, Jan 29, 2011 at 9:28 PM, Dr. H. Nikolaus Schaller
wrote:
> 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
>
On Sat, Jan 29, 2011 at 9:13 PM, Fred Kiefer wrote:
>
> Not using alloc/free always gives you a big benefit. The question is how
> this pays out in over all memory usage.
Any queue sure can be tuned to have limits. Actually I just found that
in my test I spent more time in messagings than mallocs
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 wrote:
>>
>>> (My NSApp has this implementation, allowing it to store parameters
>>> instead of real event on a fixed size loop queue which can migra
Am 28.01.2011 15:53, schrieb Banlu Kemiyatorn:
> On Fri, Jan 28, 2011 at 5:39 PM, Banlu Kemiyatorn 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 colle
On Fri, Jan 28, 2011 at 10:33 PM, Richard Frith-Macdonald
wrote:
>
> On 28 Jan 2011, at 14:53, Banlu Kemiyatorn wrote:
>> 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 unio
On 28 Jan 2011, at 14:53, Banlu Kemiyatorn wrote:
> On Fri, Jan 28, 2011 at 5:39 PM, Banlu Kemiyatorn 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
On Fri, Jan 28, 2011 at 5:39 PM, Banlu Kemiyatorn 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
No worry. anyway, the current design is broken because.
1) Filter X event like that is a broken approach, for example, it
would break the meaning of zig-zag movement. The filtering strategy
should rely on distance and time one a _fixed size buffer_ (As any
display server does to prevent frozen app
Am 27.01.2011 07:13, schrieb Banlu Kemiyatorn:
> I would like to apologize for the flame I didnt meant to. But I was
> out of the line since I didnt try to flame in the first place and so
> I didnot like it to be thought of that way. However, as I think it
> was too hard to communicate, I've decide
I would like to apologize for the flame I didnt meant to. But I was out of the
line since I didnt try to flame in the first place and so I didnot like it to
be thought of that way. However, as I think it was too hard to communicate,
I've decided that for a while that my future dev will rely on m
- Original message -
> Am 26.01.2011 11:34, schrieb Banlu Kemiyatorn:
> > On Wed, Jan 26, 2011 at 4:33 PM, Fred Kiefer wrote:
> >
> > > I don't even think we need to move the event queue from
> > > GSDisplayServer to NSApplication for that. The difference between
> > > your and my positio
Am 26.01.2011 11:34, schrieb Banlu Kemiyatorn:
> On Wed, Jan 26, 2011 at 4:33 PM, Fred Kiefer wrote:
>
>> I don't even think we need to move the event queue from GSDisplayServer
>> to NSApplication for that. The difference between your and my position
>
> For that, what is "that" ?
"That" would
On Wed, Jan 26, 2011 at 4:33 PM, Fred Kiefer wrote:
> I don't even think we need to move the event queue from GSDisplayServer
> to NSApplication for that. The difference between your and my position
For that, what is "that" ?
> is mostly that I see these extra NSEvents as a much bigger problem
BTW, I am sorry for this but I am now to busy with something else so I
won't touch these backend and event handling stuffs again so I won't
continue working on these. Tripple sorry!
Cheer.
On Wed, Jan 26, 2011 at 5:34 PM, Banlu Kemiyatorn wrote:
> On Wed, Jan 26, 2011 at 4:33 PM, Fred Kiefer wro
Am 26.01.2011 01:41, schrieb Banlu Kemiyatorn:
> - Original message -
>> Yes, this seems to have changed in the documentation. Best we can do is
>> to write a few tests on Cocoa to see what the actual behaviour is and
>> then implement an addition method on GSDisplayServer if needed.
>>
>>
- Original message -
> Yes, this seems to have changed in the documentation. Best we can do is
> to write a few tests on Cocoa to see what the actual behaviour is and
> then implement an addition method on GSDisplayServer if needed.
>
> With regards to the event compression, could you plea
Yes, this seems to have changed in the documentation. Best we can do is
to write a few tests on Cocoa to see what the actual behaviour is and
then implement an addition method on GSDisplayServer if needed.
With regards to the event compression, could you please provide examples
how we could get th
Apple docs said that NSWindow -discardEventsMatchingMask:beforeEvent:
should just forward to NSApp
but a note on NSApplication -discardEventsMatchingMask:beforeEvent: states
"Typically, you send this message to an NSWindow object, rather than
to the application object. Discarding events for a wind
21 matches
Mail list logo
