Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
There is this nifty control called NSScrollView which implements a window with scroll bars. It would store the already drawn content in a buffer and when the control is scrolled, rather then redrawing everything it will only redraw the new portion (i.e. that which wasn't visible before), and copy the part of the previous image from the buffer. For example, if you scroll half a page up, the NSScrollView will copy the bottom half of the old image which now becomes the upper part of the new image. Only the bottom part of new image has to be rendered.
When I used to program under windows, long time ago :eek:, the scroll view content update was left to the developer...

So, if those optimizations are already being used, and if the scaling is offloaded to the GPU, then why the lag is still observable? What did Mac OS X engineering team miss? When I say lag, I am not only referring to scrolling heavy realtime updated content mentioned by other posters, but also to mission control stuttering...

Although I don't own a rMBP, I have been many times and spent many hours testing and playing around @local apple store... more than some fanboys who own a rMBP and use it mainly to show off and post duplicate sect craps on MR...:D
 
So, if those optimizations are already being used, and if the scaling is offloaded to the GPU, then why the lag is still observable? What did Mac OS X engineering team miss? When I say lag, I am not only referring to scrolling heavy realtime updated content mentioned by other posters, but also to mission control stuttering...

I have a hypothesis about mission control — with many windows present on the screen it takes a bandwidth hit to get them all into VRAM (and maybe some of them must be redrawn). This could be offset by keeping mipmap chains of the window buffers. I have no idea about the scrolling lag. And in all honesty, the time I was able to test a rMBP (mine should be delivered next week, so I will do more testing), I never noticed more lag than on any other computer (e.g. TheVerge lags on my older MacBook Pro to the same degree).

There will be still bugs and missing optimisations. I doubt that the entire Cocoa framework (the UI class library) has been optimised completely for retina compositing (as far as avoiding unnecessary work does), simply because its quite a titanic undertaking. And people have also reported performance hit with fan views in the Dock — an obvious bug (I can imagine that it was being constantly repainted for no good reason). I am sure that the things will improve on the software side.
 
Lag is almost inevitable on 1920x1200. I tried it on 6 different retina computers at the apple store, but my test site was theverge which has a lot of images and I scrolled from top to bottom very fast (more like a flick).

I got like 1 frame per second.

LOL. Just no.

I get no lag at 2880 x 1800 on Windows, in IE9 of all browsers as well.

Any scrolling issues or GUI "lag" is down to Mac OS X itself. Chances are it wont work properly at all, ever, for the first generation of rMBPs. It would either be rectified in the next major OS release or will simply be forgotten about by Apple when the rMBP gets a spec boost next year.
 
LOL. Just no.

I get no lag at 2880 x 1800 on Windows, in IE9 of all browsers as well.

Any scrolling issues or GUI "lag" is down to Mac OS X itself. Chances are it wont work properly at all, ever, for the first generation of rMBPs. It would either be rectified in the next major OS release or will simply be forgotten about by Apple when the rMBP gets a spec boost next year.

You don't understand how the scaling on the retina display works at all. 1920x1200 renders at 3840x2400 and is then scaled down (also uses processing power) to fit the 2880x1800 display. The rendering itself is happening at a way higher resolution.

"Best for retina" mode renders at 2880x1800 and scales down to make it seem like 1440x900 but with more clarity. The scaling uses processing power, so, actually, windows on 2880x1800 (native) is the lowest lag config since you're rendering at 2880x1800 (same as best for retina mode) but you're skipping the scaling cycles completely.

Funny how people jump to conclusions on things like these. It's not a software issue anymore with ML - 1920x1200 WILL lag. The hardware simply cannot keep up with 9.2 million pixels...
 
Funny how people jump to conclusions on things like these. It's not a software issue anymore with ML - 1920x1200 WILL lag. The hardware simply cannot keep up with 9.2 million pixels...

Computer games take much more processing power then that. And 9.2 million pixels is not that much. Even HD 4000 has pixel fillrates way over 1Gpixel/sec.
 
You don't understand how the scaling on the retina display works at all. 1920x1200 renders at 3840x2400 and is then scaled down (also uses processing power) to fit the 2880x1800 display. The rendering itself is happening at a way higher resolution.

"Best for retina" mode renders at 2880x1800 and scales down to make it seem like 1440x900 but with more clarity. The scaling uses processing power, so, actually, windows on 2880x1800 (native) is the lowest lag config since you're rendering at 2880x1800 (same as best for retina mode) but you're skipping the scaling cycles completely.

Funny how people jump to conclusions on things like these. It's not a software issue anymore with ML - 1920x1200 WILL lag. The hardware simply cannot keep up with 9.2 million pixels...

Of course I understand it. You just enjoy being pretentious and (attempting) to put people in their place.

Sadly on this occasion, you failed.
 
"Best for retina" mode renders at 2880x1800 and scales down to make it seem like 1440x900 but with more clarity.

I thought the rendering was made at 2880x1800, HiDPI mode, at "best for retina" (apps not supporting retina being taken care of as a special case). No scaling should be needed after that. As you say, the other "resolution options" such as "1920x1200" would require scaling after rendering, since the first rendering is not done at 2880x1800.
 
Computer games take much more processing power then that. And 9.2 million pixels is not that much. Even HD 4000 has pixel fillrates way over 1Gpixel/sec.

Yeah, but I believe most of modern computer games do 3D vectorial rendering, while retina is probably doing 2D rendering and bitmap buffers manipulations. Shouldn't drawing vectorial shapes without textures mapping, shadow, light,... be faster than bitmap manipulation? :). Also, computer games would probably require a discrete gpu to run smoothly, while desktop gui "should in theory" only require the integrated gpu. If not, then one might ask himself what is the purpose of the integrated gpu?...
 
Last edited:
Yeah, but I believe most of modern computer games do 3D vectorial rendering, while retina is probably doing 2D rendering and bitmap buffers manipulations. Shouldn't drawing vectorial shapes without textures mapping, shadow, light,... be faster than bitmap manipulation? :). Also, computer games would probably require a discrete gpu to run smoothly, while desktop gui "should in theory" only require the integrated gpu. If not, then one might ask himself what is the purpose of the integrated gpu?...

OS X is using 3D hardware for desktop compositing (flat textured quads with orthogonal projection + shaders for effects), as does Windows since Vista and Linux since existence of the compiz window manager ;)

Bitmap buffer manipulation is of course a significant part of all this, as many things, like text, are rendered by the CPU into the buffer. Modern OSes use special acceleration features to quickly transfer the data between the system memory and video memory.

And BTW, where did you see a game which wouldn't use textures and lights o_O Modern IGPs like HD4000 are able to competently run games with lower settings.
 
I still think its software based seeing as 2880 x 1800 is smooth as silk and so is using it on the TB display. It's not the hardware that can't handle it but the software just isn't optimized yet.
Rendering to 3840×2400 and downsampling that to 2880×1800 is considerably more intensive than simply rendering at 2880×1800 without doing any scaling.

It’s also possible that rendering 3840×2400 pushes the GPU beyond its limits. 2880×1800 may be right on the upper edge of what it can handle smoothly. 2880×1800 is 5.2MP of data, whereas 3840×2400 is 9.2MP of data that is not only being rendered, it’s being rendered and then scaled.


While there’s no momentum-based scrolling in 10.6.8, which is probably a contributing factor, I thought it was funny that people are having problems with scrolling lagging on the Retina MacBook Pro, when the “ancient” MacBook 1,1 I’ve been using the past few days has no problem with it. (in Firefox, lags in Safari)

The lag debate is one of those discussions which is completely pointless. It's an entirely subjective experience and to say it's definitive one way or another is moot.
I don’t think it’s subjective at all. It is something that can be objectively measured.

Whether it bothers someone, or if they notice it, is another matter entirely.
 
If you go pick up RDM and play around a bit, it's extremely obvious that the downsampling is the culprit.

Simple test:

Setup:
* Pick a folder with a large number of files (I used /Applications)
* Drag that folder to the right side of the Dock to create a stack.
* Set that stack to display as a list.
* Verify that the list is long enough to scroll

1440x900 / 2880x1800
* Set resolution to "Best for Retina" (1440x900 HiDPI)
* Pop up the list, and scroll. Notice that it's rather jerky.
* Set resolution to 1440x900 (non HiDPI) using RDM.
* Pop up the list and scroll. Silky smooth.
* Set resolution to 2880x1800 using RDM
* Pop up the list and scroll. Silky smooth.

1920x1200 / 3840x2400
* Set resolution to 1920x1200 HiDPI
* Pop up the list and scroll. Jerky.
* Set resolution to 1920x1200 (non HiDPI) using RDM
* Pop up the list and scroll. Silky smooth.
* Set resolution to 3840x2400 using RDM
* Pop up the list and scroll. Not quite silky smooth.

Anything that uses the downsampling is jerky. Anything that doesn't is smooth (with the exception of 3840x2400, which is above native and isn't being downsampled so much as downscaled. However, even that's noticeably faster than the downsampled HiDPI modes.)

Personal experience under both 10.7 and 10.8 shows that it's definitely *better* under 10.8, but still there. It doesn't go away when switching to the nVidia chipset - but it does seem a bit less jerky when using the discrete card.

My gut says there's still some software optimizations to be made with the way they're doing the downsampling, but that Apple may simply say this is "good enough for now" and wait for the next-gen chips from Intel/nVidia to shove all that under the rug.

That having been said, the current situation is nowhere near "unusable", particularly if you limit it to 1440x900 HiDPI. A little jerky here and there, but not IMHO the complete disaster some are claiming it to be.
 
I find the vast majority of websites on the rMBPto be fine, with one of the notable exceptions being TechCrunch.
 
Why does the downsampling work just fine on the iPad 3? The iPad 3 has only 50% less pixels than the RMBP, but a many times slower processor and GPU...

Also, why does Apple down-sample, instead of just upping the number of resolution elements for GUI interface elements such as browser windows and associated text? In other words have the same as the "native" 2880x1800 mode one can so nicely achive with SwitchRes, but with bigger GUI elements so that I can still read the font on my menu bar, browser tabs, email client, etc etc?

A while ago I was on a thread here where people claimed that the crucial new feature of ML would be that it would allow just that, independent scaling of GUI elements (not sure I'm using the right terminology here, but I hope it's clear from the context) and content (images, etc).

According to what people say in this thread the culprit for lag of RMBP is, this would be just the solution to the issues. Is it what's implemented on the iPad?
 
Why does the downsampling work just fine on the iPad 3? The iPad 3 has only 50% less pixels than the RMBP, but a many times slower processor and GPU...
The iPad is natively rendering at 2048×1536, there is no downsampling involved. It’s also limited to running one app at a time, and apps are specifically coded for it.

The Retina MacBook Pro natively renders at 2880×1800.

When you select the 1680×1050 or 1920×1200 options, it is rendering above the display’s native 2880×1800 resolution, at 3360×2100/3840×2400, and then downsampling that result to 2880×1800.

Also, why does Apple down-sample, instead of just upping the number of resolution elements for GUI interface elements such as browser windows and associated text? In other words have the same as the "native" 2880x1800 mode one can so nicely achive with SwitchRes, but with bigger GUI elements so that I can still read the font on my menu bar, browser tabs, email client, etc etc?
It is significantly easier to support 1× and 2× scaling than it is to support arbitrary scaling of UI elements. This is why the Retina MacBook Pro renders 1920×1200 at 2× (3840×2400) and then scales down the resulting image to fit the display’s 2880×1800 resolution.

It would be considerably more complicated, and produce much worse results if Apple were to render the UI with a scale of 1.72× (1680×1050) or 1.5× (1920×1200) rather than render at 2× and scale it down, as they do now, especially once more Macs have retina displays.

I doubt you would have the option for anything other than 1440×900@2×, or 2880×1800@1× if they didn’t implement this downscaling. I’m actually surprised it exists at all.
 
I thought the rendering was made at 2880x1800, HiDPI mode, at "best for retina" (apps not supporting retina being taken care of as a special case). No scaling should be needed after that. As you say, the other "resolution options" such as "1920x1200" would require scaling after rendering, since the first rendering is not done at 2880x1800.

You are correct. The only scaling that goes on in "Best for Retina" mode is the pixel-doubling of apps that aren't retina ready.
 
Thanks for the explanation.

What I still don't understand is why there can't be a 2880x1800 mode with larger UI elements? If run at 2880x1800 everything is zippy and crisp, the only problem being that it's hard to read text on UI elements and hard to e.g., drag them because the window frame is so small.

The iPad is natively rendering at 2048×1536, there is no downsampling involved. It’s also limited to running one app at a time, and apps are specifically coded for it.

The Retina MacBook Pro natively renders at 2880×1800.

When you select the 1680×1050 or 1920×1200 options, it is rendering above the display’s native 2880×1800 resolution, at 3360×2100/3840×2400, and then downsampling that result to 2880×1800.

It is significantly easier to support 1× and 2× scaling than it is to support arbitrary scaling of UI elements. This is why the Retina MacBook Pro renders 1920×1200 at 2× (3840×2400) and then scales down the resulting image to fit the display’s 2880×1800 resolution.

It would be considerably more complicated, and produce much worse results if Apple were to render the UI with a scale of 1.72× (1680×1050) or 1.5× (1920×1200) rather than render at 2× and scale it down, as they do now, especially once more Macs have retina displays.

I doubt you would have the option for anything other than 1440×900@2×, or 2880×1800@1× if they didn’t implement this downscaling. I’m actually surprised it exists at all.
 
Thanks for the explanation.

What I still don't understand is why there can't be a 2880x1800 mode with larger UI elements? If run at 2880x1800 everything is zippy and crisp, the only problem being that it's hard to read text on UI elements and hard to e.g., drag them because the window frame is so small.
That’s exactly what the 1440×900@2× (HiDPI) mode is.

It’s not feasible to run at non-integer resolutions like 1680×1050@1.72× or 1920×1200@1.5× because non-retina applications in particular will look shockingly bad.

You have to render at 2×, which means 3360×2100/3840×2400, and downscaling the final image to 2880×1800.

The alternative is that you only offer 2×, and have the option of 2880×1800 (Native) or 1440×900@2× (HiDPI) and don’t have scaled modes at all. It’s not like that was ever an option in the past. With previous generations of MacBook Pro, you had to specify whether you wanted the 1440×900 or 1680×1050 panel, and that’s all you got.

Hopefully next year they will offer a 3360×2100 native panel so you will have 1680×1050@2× to have more workspace without resorting to downscaled resolutions. (though it will still be downscaled if you want 1920×1200 workspace)
 
If you go pick up RDM and play around a bit, it's extremely obvious that the downsampling is the culprit.

Simple test:

Setup:
* Pick a folder with a large number of files (I used /Applications)
* Drag that folder to the right side of the Dock to create a stack.
* Set that stack to display as a list.
* Verify that the list is long enough to scroll

1440x900 / 2880x1800
* Set resolution to "Best for Retina" (1440x900 HiDPI)
* Pop up the list, and scroll. Notice that it's rather jerky.
* Set resolution to 1440x900 (non HiDPI) using RDM.
* Pop up the list and scroll. Silky smooth.
* Set resolution to 2880x1800 using RDM
* Pop up the list and scroll. Silky smooth.

1920x1200 / 3840x2400
* Set resolution to 1920x1200 HiDPI
* Pop up the list and scroll. Jerky.
* Set resolution to 1920x1200 (non HiDPI) using RDM
* Pop up the list and scroll. Silky smooth.
* Set resolution to 3840x2400 using RDM
* Pop up the list and scroll. Not quite silky smooth.

Anything that uses the downsampling is jerky. Anything that doesn't is smooth (with the exception of 3840x2400, which is above native and isn't being downsampled so much as downscaled. However, even that's noticeably faster than the downsampled HiDPI modes.)

Personal experience under both 10.7 and 10.8 shows that it's definitely *better* under 10.8, but still there. It doesn't go away when switching to the nVidia chipset - but it does seem a bit less jerky when using the discrete card.

My gut says there's still some software optimizations to be made with the way they're doing the downsampling, but that Apple may simply say this is "good enough for now" and wait for the next-gen chips from Intel/nVidia to shove all that under the rug.

That having been said, the current situation is nowhere near "unusable", particularly if you limit it to 1440x900 HiDPI. A little jerky here and there, but not IMHO the complete disaster some are claiming it to be.

I couldn't get setres (program) to do 1920 x 1200 (non-HDPI) are you using something else?
 
I still think its software based seeing as 2880 x 1800 is smooth as silk and so is using it on the TB display. It's not the hardware that can't handle it but the software just isn't optimized yet.

Interesting comment for sure.

I'm running a 13" mid-2010 with the GeForce 320M and 2.4GHz C2D with 4GB RAM awaiting my rMBP's arrival and it's driving my LED Cinema Display at 2560*1440 with just a *hint* of display lag. It's a touch slower than my early 2011 QC i7 15".

The enormously slower than rMBP mid-2010 13" shows almost imperceptible lag. The rMBP should theoretically drive it's display with no problems unless there is an inherent inefficiency with the way it runs "virtual" resolutions.

With regards to downscaling, I tried the 13" with cinema display combo at 2048*1152 and 1600*1200 letter-boxed and there is definitely a touch more lag.

Could someone with a rMBP and cinema display test to see if the lagging continues when driving the cinema display?
 
@OP: The website doesn't scroll smooth but it is nothing that bothers me much.
Interestingly the CPU usage of Safari-Webcontent goes up to 60% when scrolling on that site.
 
I couldn't get setres (program) to do 1920 x 1200 (non-HDPI) are you using something else?

RDM (Retina Display Menu) is phoenixdev's updated version =)

http://www.reddit.com/r/apple/comments/vi9yf/set_your_retina_macbook_pros_resolution_to/

----------

Could someone with a rMBP and cinema display test to see if the lagging continues when driving the cinema display?

I have an LED Cinema Display (last version before they went the Thunderbolt), and can verify that it's smooth at native resolution (2560x) - no lag/hitchiness at all.

Edit: I should add that connecting to the external display switches over to the nVidia chipset, so any failings of the Intel chipset wouldn't come into play.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.