Some people's brain & eyes are quick enough to see the difference between the 20fps and 40fps scroll difference, on certain sites, between the rMBP and cMBP. If your brain can't process the video info fast enough (detect dropped frames), then you probably won't notice the lag on the rMBP.
sigh. why do people still think performance comparisons of 2880 native res is the same thing as 2880 res SCALED for retina display? obviously theres going to be much more processing going on in the latter.
I see some lag on my 2009 MBP on that website
Maybe its just layout? BTW, Chrome is smoother than Safari here...Ah, the old good stevelam, as always 'stating the truth' without no argument beyond 'its like that because its like that'.
You mean the "Best for Retina" 2880x1800 mode with HiDPI enabled?
I think Apple's engineers are smart enough to know how to efficiently upscale a 1920x1200 image to 3840x2400 and down scale it to 2880x1800. My understanding is this 2D operations have to be done at least 25 times per second. Who does handle these ops, the CPU?, or are they offloaded to the GPU?I see some lag on my 2009 MBP on that website
----------
Ah, the old good stevelam, as always 'stating the truth' without no argument beyond 'its like that because its like that'.
Honestly, I see no reason for scaled being slower then native. Actually, 'real' 2880x1800 could be more work as you'll have to display more UI elements (depending on situation). With scaled resolution, you have to supersample the UI (quadrupling the work associated with drawing of text etc.). With native resolution, you have 4x content. E.g. a full-screen window in native mode is comparable amount of rendering work to a full-screen window in scaled mode; but with each additional UI element comes a setup cost. It might be actually cheaper to render one sentence at 4x resolution than 4 sentences at 1x resolution due to the setup cost. And btw, if you are concerned about the overhead of upscaling images or using higher-res image data, don't be - hardware is designed for 3D games which are way more intensive in that regard.
Of course, in the end it all depends how the software actually works... OS X might be doing some 'stupid' things in scaled mode which will slow things down (it probably is).
They are not upscaling 1920x1200 to 3840x2400, that would be an incredibly silly thing to do. Instead, they render the desktop (at 2x2 UI size) to a 3840x2400 buffer (which is basically a 2x2 supersampled 1920x1200) and then downscale it to 2880x1800. The scaling is done on the GPU, performed by the texture filtering hardware.
Sorry, I meant supersampling a bitmap image and not upscaling it with mosaic effects
Source of information?
Isn't 25 FPS the minimum rate that makes the frames substitutions indistinguishable to the eyes' retina?
The optimization idea is good, but I think it would be very complicated or impossible to implement...
"Common sense ®"
Its not that simple or gamer's won't be insisting on their 60fps figures. You are talking about movies with their 24fps default temporal resolution — but its an entirely different piece of cake as movies automatically exhibit motion blur and thus actually have more information in them. Without this blur, 24fps looks very choppy. In the end, the necessary frame rate depends on the content. Computer monitors have refresh rate of 60 frames per second, which seems to work nice.
No, its actually rather easy and the default rendering on OS X has worked this way for years now — only changed elements are redrawn. The tricky bit is only blitting over the changed part (while downsampling it) to the final buffer as downsampling only the part of the image could possibly result in visual artefacts (I don't have the time to run the math now), but its entirely manageable.
I've read in this forum that someone observed high CPU usage with Activity Monitor when scrolling with Safari...
I understand that an application window is a view and is a container of several other views such as button, listbox, scrollbar, textarea, canvas,...etc. Every view element has a refresh method that allows it to redraw itself whenever needed. When a window needs to refresh, all its ui elements refresh method is called. The refreshing takes into account the window Z-order in order to optimize it. Also, your desktop is a ui element, a kinda of super container of all your applications' windows.
Sure, because much of the rendering (for instance text, if I am not mistaken ), is done by the CPU. Because scrolling involves lots of content update very quickly, the CPU will get taxed.
You talk about a model which is used by old Windows GUI
OS X and modern Windows (.NET) work very differently from that, and some really cool stuff is possible. 
