rtitmuss
2007-09-26, 12:45
A few bugs relate to the jive sounds effects, sometimes they play at in appropriate moments or they are not timely with respect to button presses. In particular this is a problem with the 'forward', 'back' and 'bump' sounds. Currently they are played with window transitions, and not when the key presses happen. The transition may happen without a key press (for example the flickr applet), or may be slightly delayed from the key press (for example when fetching data from the network).
I think ideally the playback of the sound effect needs to be moved to the event main event processing, and done before any widget callbacks happen so the sound is more timely with the key press. The problem with this is often the callback will determine what sound effect should be played, for example the menu callback determines if a new window is being pushed or a bump should happen.
So to achieve the desired effect the existing way events are processed in Jive needs to be modified. At the moment event handlers can be registered for key type events, for example a 'key press' event. I think this needs to be finer grained, so that a handler would be registered for a 'play key press' event. Along with the handler an optional sound effect could be included, this sound effect would be played before the handler is called providing more timely feedback. Only one handler per event per widget would be supported. If needed widgets could be chained together by the application. Given a typical widget hierarchy of 'Window > Menu > Label' then the event processing would start with the Label. If no event handler was registered, then Menu would be checked and finally Window. The global event handlers would still need to allow processing on any key press, for lock screen, screensavers, power saving, etc. I have not yet thought how that would be incorporated.
This change would remove several if/then/else ladders for event processing and result in more functions/closures. The event processing would then mainly be a table look up. This may result in a modest speed up, but current profiling suggests the layout/drawing code is the biggest overhead on ARM so the impact on performance will be small.
Any suggestions or comments?
I think ideally the playback of the sound effect needs to be moved to the event main event processing, and done before any widget callbacks happen so the sound is more timely with the key press. The problem with this is often the callback will determine what sound effect should be played, for example the menu callback determines if a new window is being pushed or a bump should happen.
So to achieve the desired effect the existing way events are processed in Jive needs to be modified. At the moment event handlers can be registered for key type events, for example a 'key press' event. I think this needs to be finer grained, so that a handler would be registered for a 'play key press' event. Along with the handler an optional sound effect could be included, this sound effect would be played before the handler is called providing more timely feedback. Only one handler per event per widget would be supported. If needed widgets could be chained together by the application. Given a typical widget hierarchy of 'Window > Menu > Label' then the event processing would start with the Label. If no event handler was registered, then Menu would be checked and finally Window. The global event handlers would still need to allow processing on any key press, for lock screen, screensavers, power saving, etc. I have not yet thought how that would be incorporated.
This change would remove several if/then/else ladders for event processing and result in more functions/closures. The event processing would then mainly be a table look up. This may result in a modest speed up, but current profiling suggests the layout/drawing code is the biggest overhead on ARM so the impact on performance will be small.
Any suggestions or comments?