Latest WebKit Build Doubles Scrolling Performance on MacBook Pro with Retina Display
by Anand Lal Shimpi on December 4, 2012 11:51 AM EST- Posted in
- Mac
- Apple
- MacBook Pro
In both of our MacBook Pro with Retina Display reviews (13-inch & 15-inch), I pointed out a big downside to the user experience today: UI performance in some applications is significantly reduced compared to non-Retina models. I couldn't find a direct cause for the issue, just that whatever work Apple does to make OS X look like OS X ends up requiring quite a bit of CPU power, and the workload scales with resolution. I've seen this in applications like Mail and Safari, although it's present in more than just that.
In our 13-inch rMBP review I proposed a couple of solutions: 1) a dramatic increase in single-threaded CPU performance, and/or 2) software improvements (e.g. the move to Mountain Lion for example shifted more animation workload over to the GPU, improving scrolling performance vs. Lion on rMBPs).
Last week I received a tip (thanks Joan!) pointing me at a Macrumors post claiming that the latest nightly builds of WebKit fixed scrolling performance on the rMBP. I grabbed a build (r135516 - it's no longer the latest build but I assume the later builds also contain the fix) and tried it out on the 13-inch rMBP. Scrolling down my Facebook news feed ended up being one of the best showcases for poor scrolling performance on the rMBPs, so that's obviously the first test I ran. As always I used Quartz Debug to measure UI frame rate. First, here's what the average frame rate looked like using the latest version of Safari on Mountain Lion with the 13-inch rMBP running at the scaled 1440 x 900 setting:
13-inch rMBP, 1440 x 900 scaled setting, Safari Version 6.0.2 (8536.26.17)
Average frame rates end up being around 20 fps, with dips down as low as 17 fps. Now here's the same test but using the r135516 WebKit build:
13-inch rMBP, 1440 x 900 scaled setting, WebKit Nightly r135516 Safari Version 6.0.2 (8536.26.17, 537+)
Performance is more than doubled! Scrolling is so much smoother. I also ran tests on pages that previously worked fine (e.g. the AnandTech front page) and performance hadn't changed there. I haven't managed to figure out exactly what's changed in the codebase to improve performance so much but it's appreciable.
For those of you who are early adopters of Retina MBPs, there looks to be some hope that we might see software solutions to improving UI performance. The real question is when we'll see these types of improvements rolled into OS X.
Facebook
Twitter
RSS
15 Comments
View All Comments
trek179 - Tuesday, December 4, 2012 - link
Dear Anand, this is great news! I was just wondering what tool do you use to measure the FPS? Thanks!xilience - Tuesday, December 4, 2012 - link
From just above the first framerate picture:"As always I used Quartz Debug to measure UI frame rate."
trek179 - Tuesday, December 4, 2012 - link
Thank you xilience and coder543.I am stupid.
coder543 - Tuesday, December 4, 2012 - link
"As always I used Quartz Debug to measure UI frame rate."trek179 - Tuesday, December 4, 2012 - link
My bad!zeagus - Tuesday, December 4, 2012 - link
I just installed the most recent nightly as of this writing and the speed is definitely there. Going to check actual framerate in Quartz Debug as you did. VERY nice improvement, however.tipoo - Tuesday, December 4, 2012 - link
Last I checked, under Mountain Lion, things like the calender flip animation and a few other things were so slow you could count the frames out on. The green button resize was sometimes slow, although to a lesser degree, you may not notice until you have another modern non-retina mac side by side with it.shalevy - Tuesday, December 4, 2012 - link
Dear Anand,Since it seems like the problem is SW and is related to Webkit (java script?) engine, I was wondering if/why the iPad with retina display would not suffer the same if not more of this performance problem.
Here is my thinking: my MBPr 15'' scores 147ms on the sunspider benchmark. This is compare to the ~900ms of the iphone 5, so the ipad 4 should be maybe 20% faster. This gives the MBPr about 6X more single threaded performance in Webkit.
MBPr (15 inch) needs to render 1.6x more pixels and also Mac OSX is doing colour proofing, while iOS doesn't. I would think both of those are more GPU related, but lets assume they are CPU. So this reduces the 6X to 1.875X more single threaded performance for rendering pages.
I would assume iPad with retina is even worse at web page scrolling, is that the case? Was that tested? If it was tested and the performance is better on iPad than on MBPr, is there any idea why?
Thanks!
lowlymarine - Tuesday, December 4, 2012 - link
iOS Safari renders each web page into a texture as it is loaded, and when you scroll/translate the page, the GPU works with that texture rather than having the CPU render the web page directly. This allows the iPad to scroll pages smoothly provided they don't have too many moving elements that can't be rendered in this manner, at the expense of that little gray checkerboard pattern coming up if you scroll beyond the edge of the texture. Safari on Mac doesn't do this because generally speaking it shouldn't be necessary - any modern x86 CPU is dozens or even hundreds of times faster than even the fastest ARM chips, depending on workload, after all.I suspected the issue here was less one of hardware and more of poor software optimization, and it now appears that was the correct hypothesis. I'm curious, since I haven't seen it mentioned: do Chrome, Firefox, and Opera experience these same slow scrolling issues on the rMBP?
tipoo - Tuesday, December 4, 2012 - link
Interesting, I had not heard of that. For the last few revisions, Chrome on desktop seems to have that checkerboard pattern when I scroll too fast too, I don't remember it doing that before, it just stopped before the end of the rendered page. I wonder if it is using the same method? Or if it's inherent in the newly GPU accelerated version?