POST A COMMENT

15 Comments

Back to Article

  • trek179 - Tuesday, December 04, 2012 - link

    Dear Anand, this is great news! I was just wondering what tool do you use to measure the FPS? Thanks! Reply
  • xilience - Tuesday, December 04, 2012 - link

    From just above the first framerate picture:
    "As always I used Quartz Debug to measure UI frame rate."
    Reply
  • trek179 - Tuesday, December 04, 2012 - link

    Thank you xilience and coder543.

    I am stupid.
    Reply
  • coder543 - Tuesday, December 04, 2012 - link

    "As always I used Quartz Debug to measure UI frame rate." Reply
  • trek179 - Tuesday, December 04, 2012 - link

    My bad! Reply
  • zeagus - Tuesday, December 04, 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. Reply
  • tipoo - Tuesday, December 04, 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. Reply
  • shalevy - Tuesday, December 04, 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!
    Reply
  • lowlymarine - Tuesday, December 04, 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?
    Reply
  • tipoo - Tuesday, December 04, 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? Reply
  • p_giguere1 - Tuesday, December 04, 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.
    Reply
  • Henk Poley - Tuesday, December 04, 2012 - link

    Even on older systems: MacBook3,1 Late 2007, 2GHz Core2Duo, Intel X3100 GPU, OS X 10.7.5

    Peacekeeper score:

    Safari 6.0.2: 1625
    Chrome 23.0.1271.95: 1775
    Webkit r136460:1860
    Reply
  • Henk Poley - Tuesday, December 04, 2012 - link

    Also about 2 seconds less "CPU time" on http://html5-benchmark.com

    Safari: 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.
    Reply
  • ThreeDee912 - Wednesday, December 05, 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.
    Reply
  • Streamlined - Thursday, October 24, 2013 - link

    It would be great to see a follow-up test on the newly released OSX Mavericks. Reply

Log in

Don't have an account? Sign up now