I've noticed this in videos as well. When there are a lot of flash ads on the screen, scrolling/zooming becomes very choppy. Even with a single element on-screen the effects are noticeable. It's interesting because there's a clear distinction between the browser redraw and the redraw of the flash areas on screen.

I don't think that a device with hardware like the Tab is ready for multiple flash windows just yet, but I do believe that the browser is mainly at fault for this. With some much needed optimizations, Google's browser could perform quite well despite the heavy and slow flash.

Here are my thoughts.

--------

I think performance of flash in the browser could be greatly improved with a few changes. Of course, these are based on speculation of the underlying browser architecture, so don't take too seriously:

1) GPU accelerated scrolling in the browser. This can be accomplished a number of ways, I'm sure (eg. mapping screen elements onto quads -- should work well with site transparencies)

The iPad and iPhone feature near flawless scrolling which many speculate to be because of this feature. Additionally, there is a clear separation between movement and redraw. The CPU in this instance would only be required to draw new portions of the screen and only after scrolling has taken place. What you get is an ultra-smooth window scroll, and a checkerboard board pattern that quickly disappears when the CPU has time to redraw. Similarly when zooming, it's clear that a scaling of the current window contents happens and the the CPU re-draws at the new zoom level when it is able. Again, the result is a very smooth operation.

Also less CPU activity may positively benefit battery life.

FYI anybody (with a google account) can vote for this issue here.

2) The flash window should give its content to the browser to render, and not be responsible for rendering to the screen directly.

I'm speculating that this is indeed the case, but when I see flash elements scrolling at different rates than browser scrolling, it seems as though this may be what's happening. With a single point of rendering, this would not occur, and flash would not need to be called when a scroll event fires -- an almost certainly expensive operation, especially with multiple objects on scree. It also leaves the door open

3) De-prioritization of flash in the OS scheduler. I don't know if this is the case, but flash should be given a very low priority compared to the host browser. In other words, even for a flash heavy site, flash should slow down before the browser does.

-----

Certainly the latest Chrome Dev includes GPU acceleration which the chrome team has mentioned has many speed benefits:
http://www.tomsguide.com/us/GPU-Acce...news-7895.html

I notice that even the iPad flash implementation features FLAWLESS scrolling, which leads me to believe that at least some (if not all) of these optimizations have been implemented.

I think that the Android browser is leagues behind where it should be. Though processors are becoming faster and faster, I have yet to see an Android superphone scroll a web page as proficiently as a 1st generation iPhone/iPod touch despite the technically superior hardware. And android *is* capable of it. If it can display a complex game like Need For Speed Shift, or Nova, at smooth rates, it can handle smooth scrolling. Of course the code is the bottleneck.

It remains to be seen weather or not Gingerbread will address these concerns. Here's hoping that it does, as a browser is a MAJOR application for mobile devices and arguably one of Android's largest failings to date.