Irony of the un-scrollable ML review...

Just you, fine here.

 

I have that lag as well.

 

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.

 

Doesn't lag on my early 2011 at "true" 1920x1200...fwiw.

 

The "lag or no lag" discussion on the rMBP is entirely subjective. Some people notice it immediately and sees it as a pain, and some may notice it, but do not, as it does not affect their usage behavior.

I do not have an rMBP, but I really want one. Having checked out a lot of rMBPs it is always the same, and it doesn't seem to matter if it is a Samsung or an LG panel. I wonder if this is a HW issue (which will only be fixed in v2), or "merely" a SW issue, which will be fixed ASAP?

Any ideas? I really want a new MBP, but not if I have to live with that terrible lag, which for me is really limiting my usage joy!

/Bo

 

Same with my late '11. Not a bit.

 

The areas where I found the rMBP to lag are:

-Facebook: scrolling, resizing (page, newsfeed, profile)
-Google+: scrolling, resizing (news feed, profile)
-Mac App Store: Resizing, scrolling

 

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.

Regarding the fix; ML was Apple's major attempt to eliminate the lag using software. If you still see lag on ML, chances are a s/w fix will be unobtainable with the first gen rMBP hardware.

 

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.

 

LOL - Already threaded this one:
http://forums.macrumors.com/showthread.php?t=1412196&page=4

You'll find that page lags for everyone if you pinch zoom in on it in safari. Doesn't lag in chrome beta for my retina, though.

 

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 meant 1920x1200 on the retina display, so technically 3840x2400.

 

very smooth on my rMBP

 

It's certainly real, and I've got five out of five at the office, with all users complaining. Especially since everything else is so fast, this issue is very noticeable if you are used to a fast workflow. For home or school use, it's not likely to be as bothersome.

 

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'.

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).

 

You mean the "Best for Retina" 2880x1800 mode with HiDPI enabled?

There's no scaling of the final resolution in that mode. The GPU is pushing 2880x1800 pixels with no final output scaling, the same number of pixels as in 2880x1800 'native' mode with HiDPI disabled.

The only scaling that goes on in that mode is with applications that aren't retina ready, and that's a simple pixel doubling which shouldn't be very GPU intensive.

Retina ready apps don't get scaled at all.

On the other hand in "Looks like 1920x1200" mode, the GPU has to push 3840x2400 pixels and then scale it to 2880x1800 for display. That's where you might see a performance difference.

 

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?

 

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.

Edit (didn't notice that part of the question, sorry): where does your 25 fps figure comes from? Usually people talk about 60fps... The actual number of required updates per second depends on the content. If you simply display a static image, then 1 update per second is more then enough. If you display an animation, you will have to update more often than that. Theoretically, the Intel integrated GPU has enough bandwidth and filtering power to do 3840x2400 -> 2880x1800 downscaling more then 60 times per second (but this can become a performance limiting factor if there is lots of additional work to be done). The whole thing can be also further optimised, by tracking areas on the display which have been changed and only updating these. For example, if the only changing image on the display is a website banner, there is no reason to redraw and downscale the whole screen. One could only update the portion where the banner is and then blit/downsample that portion to the display buffer.

 

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 ®"

No, really, GPUs are already very good at these things and OS X seems to be using the usual bilinear filtering which is supported in GPU hardware. If it were done on the CPU, people would see high CPU usage numbers all the time.

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.

At the OS level, my understanding is that it uses pools of buffers of the same size that are filled and displayed in a cyclic way.

If your applications' windows contains several non static content, like for instance webpages with animated gifs, and jquery animations,..etc, then only the thread feeding that canvas area is aware of it. I don't see how the OS could detect and delimit those areas... My understanding is that the it takes a continuous snapshot of your display context and displays it... If not when and how the OS technically delimit those areas?

 

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.

 

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.

In OS X, the OS itself is aware of every UI element in your application and the redraw chain is managed by the OS itself. For instance, if a button text in an application has changed, the button will notify the OS that it needs a repaint, and the OS will only invoke the repaint code of the button.

Furthermore, all windows and most controls are rendered into an off-screen buffer. This buffer is then kept. Changes to a window only seldomly require execution of the full repaint chain — usually its enough to update only the part of the buffer which has changed. A repaint code of a control does not necessarily redraws everything — it is also able to redraw a portion. Also, a control can notify the OS that only part of it has changed. For instance, a well written web browser will detect that the only changed part of the image is the banner, and notify the OS that this small area needs a repaint (this is called a dirty rect). The OS will then call the paint message (method) of the web browser window, restricting the paint area to this dirty rect. This is much more efficient than redrawing everything.

If you want an example of how far this goes, look at how scrollbars are implemented in OS X. 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.

 

I'm actually running at 1920x1200 all the time. I didn't experience any significant (annoying) lag.