<br><br><div class="gmail_quote">On Thu, Nov 25, 2010 at 8:25 PM, John M McIntosh <span dir="ltr"><<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On 2010-11-23, at 1:23 AM, Henrik Sperre Johansen wrote:<br>
<br>
> On 22.11.2010 22:08, Guido Stepken wrote:<br>
>> Need additional:<br>
>><br>
>> isOnMouseOverEvent<br>
>> isMouseGestureEvent<br>
>> isTouchGestureEvent<br>
> You could try checking out how the iOS code does support for complex events.<br>
> It's of course somewhat apple-specific, but hey, would be nice to have the same image-side representation and handling of touch-based events if possible.<br>
<br>
Apple is very very notification &event callback oriented in their iOS platform. It sleeps until you touch, then you get a touch event, you process and go back to sleep. Heck if your startup time takes too many seconds Apple nails you.<br>
<br>
For Squeak on iOS I take the touch data place on a queue and signals the event semaphore. When the squeak image polls for the event we<br>
turn the touch data into a complex event and pass it back, then is processed by the Smalltalk code to turn into synthetic mouse events. (or something).<br>
<br>
For keyboard entry, we take the key input data and turn into synthetic keystroke events, and again signal the semaphore and put on a queue for later when<br>
the Smalltalk code wakes up and calls getnextevent to see what's up.<br>
<br>
I'm not sure if anyone mentioned the other issue is that the polling loop also deals with doing the morphic redrawing so it runs a cycle of doing I think it is<br>
50 iterations a second.<br>
<br>
For WikiServer which doesn't show a squeak UI I could cut that back to doing a cycle every second or so.<br>
<br>
Oh and yet one more thing, the clock tick is yet another issue, some platforms assume they can run an interrupt 1000 a second (or more) to ensure the VM is responsive to Delay being correctly woken up to the microsecond. "PS here I am over simplify the issue & complexity of the issue" but on underpowered hardware the issues of how ioRelinquishProcessorForMicroseconds and the millisecond timer work become messy issues in relationship to CPU usage.<br>
</blockquote><div><br></div><div>Yes, we need to change this, but I think one has to change the background process and/or nothing to run behavior. In the VW VM the VM disables the heartbeat and enters some blocking call when there's nothing to do. Squeak runs the background process which calls a primitive that sleeps for a short time. The former is much better. If a delay is active as the VM does to sleep it schedules a wakeup event or supplies a timeout so that it blocks until input is available or the next delay.</div>
<div><br></div><div>We could still keep the background process and do something similar to VW, disabling the heartbeat until after the relinquish, and factoring the delay into the relinquish timeout.</div><div><br></div><div>
Also the heartbeat already has facilities to change its frequency, so one could modify things to slow down the heartbeat, again ensuring that it ticks before the next delay expiry.</div><div><br></div><div>What approach (not necessarily from the above) appeals to you John?</div>
<div><br></div><div>best</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
===========================================================================<br>
John M. McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>> Twitter: squeaker68882<br>
Corporate Smalltalk Consulting Ltd. <a href="http://www.smalltalkconsulting.com" target="_blank">http://www.smalltalkconsulting.com</a><br>
===========================================================================<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br>