John M McIntosh wrote:
On 2010-01-18, at 7:36 PM, Andreas Raab wrote:
John M McIntosh wrote:
A dull iPhone 2nd generation gives 21,548,821 bytecode/sec; and 564,465 sends/sec a shinny newish iPhone 3G S gives: 42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.
Interesting! I think that means I need to play with optimizations a bit more - from what I see it looks like the 3GS runs a 600MHz ARM where the Nexus runs a 1GHz. Did you apply any optimizations i.e., gnuify, or any ARM specific stuff?
Well yes, I'm sure there has to be a beer in here somewhere, don't see it tho...
If you're going to C5 we can take care of it there :-)
No ARM specific stuff unless you consider it might have more registers than an i386...
Nah, I was just wondering if there was something specific to learn about compiler switches on ARM in terms of optimizations, say -fwoohoo-enable-super-fast-arm-dispatch or something :-)
BTW, one of the things I'm considering is to change the event type for touch events. That's mostly because it seems like on Android you actually get a coverage for a touch event, i.e., how many pixels were covered by your fatty fingers. And what I'm thinking here is that interaction could be *greatly* improved if the dispatch of such events would take coverage of the target area into account. That means that even if a click doesn't land "on" a relatively small button that the button will get the click if it's the ui element with the largest coverage in the region. I could see this working very well for relatively small UI elements. However, that does require extra information (pressure, coverage) and I'm wondering if it's worthwhile to package and dispatch those events separately. How does this level of stuff work on the iPhone? Are you dispatching touch events ore are you dispatching mouse events? Any additional parameters you're passing along?
Cheers, - Andreas