Let us pretend that you are working on an application and making heavy use of embedded webkit views. On IOS, you know this means you don't get Nitro, but the 4.2 engine is plenty fast enough to draw a canvas at 30fps. Let's also assume you are using DOM touch events, and handle touchstart, touchmove, touchstop, and touchcancel (which I have yet to see anywhere in my logs BTW). You would like to process one touch event every 33ms, so as to maintain the fidelity of your interface. Not too much to ask as the hardware on the Xoom is firing off native Android events for move every 5ms. But wait, it is not that easy.
WebViews on Android are a very nasty business. Webkit runs in a separate process, not thread, and all communication to your WebKit engine is brokered by a dalvik thread running parallel to your main UI thread. This EventHub thread translates Android messages into a queue of events that are fed to Webkit via a native binding. What this means is your WebKit view receives all input on a delay. This delay when added into the fudge factor timings used for the browser, 50ms between motion events(vs 5 native), 1000ms long press (but apparently 200ms on the Xoom breaking touchmove with one finger most of the time), and a turn around time of 60-100ms for the draw event, means it is effectively impossible to draw a webkit app at better than 16fps on the latest tablets.
While you can override most of these input settings by subclassing WebView and adding your own gesture recognizers, the 60+ms turn around time, and short circuit logic which drops frames that take "too long" to draw, often means you are effectively rate limited to 10fps, whenever you start dropping frames (if I remember correctly long draws are >100ms, but I need to check the source again). This sorts of long draws happen any time you pull an asset from SD or over the network. This is also why many apps seem to go unresponsive, because they aren't being drawn.