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.
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.
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?
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?
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?
Glad this is getting some attention, as it is fixing the biggest flaw IMO on what could otherwise be a near-perfect computer.
WebKit has a couple issues and will occasionally crash, but I was so annoyed by the scroll lag that it seems 100% worth it.
It will even import everything (open tabs, history, extensions, passwords) from Safari the first time you launch it, so it doesn't feel like you're actually switching browser.
WebKit nightlies are usually quite a bit faster than stable Safari, but like other beta software there's a few bugs that pop up here and there.
The good thing about running WebKit nightlies on OS X is that it uses all the same bookmarks, settings, and passwords (in Keychain) as stable Safari, so you can easily switch between the two.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
15 Comments
Back to Article
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?p_giguere1 - Tuesday, December 4, 2012 - link
Hey, that's my post on MacRumors!Glad this is getting some attention, as it is fixing the biggest flaw IMO on what could otherwise be a near-perfect computer.
WebKit has a couple issues and will occasionally crash, but I was so annoyed by the scroll lag that it seems 100% worth it.
It will even import everything (open tabs, history, extensions, passwords) from Safari the first time you launch it, so it doesn't feel like you're actually switching browser.
Henk Poley - Tuesday, December 4, 2012 - link
Even on older systems: MacBook3,1 Late 2007, 2GHz Core2Duo, Intel X3100 GPU, OS X 10.7.5Peacekeeper score:
Safari 6.0.2: 1625
Chrome 23.0.1271.95: 1775
Webkit r136460:1860
Henk Poley - Tuesday, December 4, 2012 - link
Also about 2 seconds less "CPU time" on http://html5-benchmark.comSafari: Score: 1999, Total CPU Time: 57.07s, Total Lag: 2615ms
Webkit: Score: 1778, Total CPU Time: 55.24s, Total Lag: 3275ms
Varies a bit though when run in succession. Webkit remains the fastest by ~2s though.
ThreeDee912 - Wednesday, December 5, 2012 - link
WebKit nightlies are usually quite a bit faster than stable Safari, but like other beta software there's a few bugs that pop up here and there.The good thing about running WebKit nightlies on OS X is that it uses all the same bookmarks, settings, and passwords (in Keychain) as stable Safari, so you can easily switch between the two.
Streamlined - Thursday, October 24, 2013 - link
It would be great to see a follow-up test on the newly released OSX Mavericks.