This has been a problem for years, but webkit has never been able to process these layouts with any kind of speed, often times scrolling itself becomes an impossible task, beach-balls and other excessive lag issues. These issues impact no other browser near as bad as webkit. This profile is but one of many examples. it's better in the 522 nightlies but still pretty bad. I've used firefox, camino, and windows IE7 to test same pages and found safari is definitely by far the slowest, to point of not even being useable.
is another url not as severe. But what I suggest is some engineers spend a good day just surfing profiles and seeing where the handicaps are. myspace isn't an important site, but it is a very popular one, one that MANY safari users hold importance on. So it should be at a high priority to be speeding up to make much more tolerable. I've had to go to point of actually blocking layout domains in hosts file just to make some profiles browsable
I would guess the fixed backgrounds are what make these pages slow to scroll.
I suspect that too, a fixed background combined with a TON of foreground images, trying to rendering all of that during scrolling. But the question still remains, why aren't other browsers nearly as bad, especially IE7, to this day I've never been able to find a single myspace profile that lags IE7 in windows. yet on same mac I can reboot it from vista back into OS X intel and test safari in it and be just as crippled as PPC mac i'm on right now.
Do you have smooth scrolling turned on in your system preferences?
I'm not sure it's as simple a fixed backgrounds, since in my experience we usually thrash Firefox at scrolling on Mac when fixed backgrounds are involved.
Another thing I have seen on some myspace pages is extreme use of opacity, as in on every table cell or something. Since IE doesn't support opacity, it avoided the giant performance hit that overuse of this property would cause. On those pages both FFX and Safari were really bad.
Firefox on Mac completely kicks our ass. Curious.
I believe different things combined add to it happening. Such as on the chubbs1111 link, the lag is being caused by two media plugins loading at once on top of background fixed image and foreground images galore. Especially notable on slower connections where the content is still loading while you're trying to scroll. Doing some testing I managed to speed things up some by removing simbl and safarisource plugin. guess rendering source coloring in a hidden window helped to contribute some but it's still pretty bad. I tried with smooth scrolling on and off it didn't seem to make much difference. Although for some strange reason when smooth scrolling was off the quicktime media on that profile caused a crash.
Thread 13 Crashed:
0 ...le.QuickTimeMPEG2.component 0x0b6074a8 CalcSourceAndDestBasePtrs + 124
1 ...le.QuickTimeMPEG2.component 0x0b605580 ReallyDecodeThePicture + 2596
2 ...le.QuickTimeMPEG2.component 0x0b5fccb4 VideoThreadEntry + 1364
3 ...le.QuickTimeMPEG2.component 0x0b5e5ef4 MacThreadFunc + 600
4 libSystem.B.dylib 0x9002bd08 _pthread_body + 96
But I don't think that's a webkit problem, looks like a definite quicktime one.
Like i said i think you just need to spend a good while browsing myspace for a while. Maybe checkout a decent mac group there with over 10,000 members, see if they can provide any insights.
shows 75% of the time is spent drawing background images while scrolling. We don't seem to be drawing them excessively... just slowly.
The background image is a giant 1280x1024 JPG. Two tables nested both have another smaller JPG tiled. The outer JPG is so large that it won't typically tile. This could be tripping up the (already-known) perf problem with how we paint a background image when we try to avoid tiling a large pattern. Rather than making the CG call to make and paint a subimage, it has been suggested that we should just be setting a clip instead. I may try that and see if it helps.
is another profile I tested with same behavior. firefox scrolling is way faster.
is using opacity. WebKit nightlies do way better with opacity than Safari 2. In a nightly that page is actually ok for me.
Firefox 3, which has switched to CoreGraphics on Mac, is so slow to scroll that it is unusable on:
Profiles show nearly half the time is being spent converting a JPEG from a BGR buffer to an RGBA buffer on every blit. This may actually be an ImageIO bug and not a WebKit bug. I have filed a Radar on them for now. Will keep this open to track the issue.
is another profile that actually beachballs safari every time you even return to tab profile is in. It looks somehow related to plugin loading (quicktime)
This hasn't been updated in awhile, it's not clear what's still relevant.
On Google Chrome 18.104.22.168 Win, which is effectively a WebKit nightly, http://www.myspace.com/bongo_me_drums is somewhat laggy when scrolling.
Bug 28392 is also about scrolling perf.