Why not using the event driven superclass rather than the polling subclass ? 2009/4/20 Igor Stasenko <siguctua@gmail.com>:
2009/4/20 Igor Stasenko <siguctua@gmail.com>:
2009/4/20 John M McIntosh <johnmci@smalltalkconsulting.com>:
Has anyone looked at how much CPU this sucks down, I'd hope the *new* logic uses less CPU when Squeak is doing nothing, than the current one which is polling every 1/50 of a second
I don't think this process eating much CPU. By my observations the most CPU hungry process (even if squeak idle) is Morphic world, which awakes each 20ms.
To be more concrete, the source of problems is a big delay (100ms) in event polling sensor. Since morphic world cycle is 20ms, its better to have same , or even smaller delay in event polling process. Otherwise, a 4 of 5 morphic world cycles receives no new events. But this not excusing the event eating behavior.. IMO something in morphic event handling is done wrong which flushing even queue or ignoring input (by considering it obsolete).
On 19-Apr-09, at 5:14 PM, Igor Stasenko wrote:
There is a mistake in update. This method is redundant. The problem is solved by simply removing that method. A method in base class (InputEventFetcher ) works with default 10 ms delays. I have posted this on issue tracker.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project