Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Sounds to me like the OP is pretty dead set in their opinion that the rMBP is a flawed product...

For me on my rMBP, I either do not notice or perceive any lag on my rMBP except in certain applications I really couldn't care less for (Mission Control).

At the end of the day, if there is any lag it does not affect my ability to perform mission critical tasks or workflows.
 
I refuse to believe that my computer can run Starcraft II on high at 60fps, but it can't render a transparency effect and some windows being rearranged at 60fps. Totally a software problem.

----------



Indeed. Apple's current solution is fundamentally inefficient. It's a software problem.

+100 to this !
 
Maybe you can be a doll and read that the lag issues were improved not fixed from what Anand said.
I am starting to sense that you cannot perceive lag. Well good for you.

What hard fact have you given me?

There are current threads of people still having lag in 2015. 3 years after rMBP was released. Some software fix. Simple logic tells me you are wrong no matter what technical facts your present.

Just looking at my Xbench results on the same computer with HiDPI vs non HiDPI tells me you are completely wrong. Dispute the Xbench results, you really can't


You are hilarious. If Anand is such an authority for you, then be a doll and look up his subsequent articles where he notes that all the lag issues he used to have were fixed by subsequent software releases. But you don't want to do that, right? That would ruin your story.



I gave you hard facts about hardware. If it does not make sense to you, refute my numbers and/or my arguments. If you can't, you are clearly not competent to make any statement whatsoever on the matter. Your appeal to authority is completely worthless.



A minor issue with a specific model. I am not aware whether it has been resolved since, but it looks to me like another instance of the SMC bug. I used to have heavy lag in my 2012 rMBP until Apple has released a firmware fix.


----------

Every product has it's flaws. Lag is something that matters to some and not to others. I think the rMBP is a great product much better than cMBP before it.

It just has this flaw that is hard to fix. It not a big deal to some people. For me it is and luckily rMBP lets me use non hiPDI 1920x1200 resolution that makes it buttery smooth.





Sounds to me like the OP is pretty dead set in their opinion that the rMBP is a flawed product...

For me on my rMBP, I either do not notice or perceive any lag on my rMBP except in certain applications I really couldn't care less for (Mission Control).

At the end of the day, if there is any lag it does not affect my ability to perform mission critical tasks or workflows.


----------

Do you even have a github profile can you program?

Do you know anything about computer hardware on the technical side? How RAS and CAS work in computer memory?

Have you ever writen a CUDA or OpenCL program?

My xbench results tell me your dead wrong.

That is what I thought. This thread is funny.
:rolleyes:
Not a great deal of technical knowledge but he knows because Anand was hired by Apple. Possibly for Qualityassurance and not software engineering but if you are hired it means everything you say is gold in every subject matter relating to Apple.:rolleyes:
 
Software or hardware it doesn't matter, there has been ui lag issues since the rMBP release and i wont spend my money on one till Apple pull their finger out and fix it.
 
Maybe you can be a doll and read that the lag issues were improved not fixed from what Anand said.
I am starting to sense that you cannot perceive lag. Well good for you.

What hard fact have you given me?

There are current threads of people still having lag in 2015. 3 years after rMBP was released. Some software fix. Simple logic tells me you are wrong no matter what technical facts your present.

Just looking at my Xbench results on the same computer with HiDPI vs non HiDPI tells me you are completely wrong. Dispute the Xbench results, you really can't




----------

Every product has it's flaws. Lag is something that matters to some and not to others. I think the rMBP is a great product much better than cMBP before it.

It just has this flaw that is hard to fix. It not a big deal to some people. For me it is and luckily rMBP lets me use non hiPDI 1920x1200 resolution that makes it buttery smooth.







----------

Do you even have a github profile can you program?

Do you know anything about computer hardware on the technical side? How RAS and CAS work in computer memory?

Have you ever writen a CUDA or OpenCL program?

My xbench results tell me your dead wrong.


Grow up.
 
Wannabe programmers trying to give technical opinions.




----------

Respect your opinion. Curious how the new AMD GPU on the rMBP compares.

Can't wait for someone to do a xbench on it.

Software or hardware it doesn't matter, there has been ui lag issues since the rMBP release and i wont spend my money on one till Apple pull their finger out and fix it.
 
Just looking at my Xbench results on the same computer with HiDPI vs non HiDPI tells me you are completely wrong. Dispute the Xbench results, you really can't

I don't give a damn about Xbench. Why? Because the the real world UI applications work differently. And the OS will throttle UI updates if they occur too quickly. So Xbench approach of triggering as many updates as the system can is ultimately flawed.

----------

Wannabe programmers trying to give technical opinions.

Its hilarious that you of all people would call people wannabe programmers :rolleyes:
 
121.jpg
 
What code have you written?

Even if the OS throttles UI if they occur to quickly. Why the difference between the HiDPI and non HIDPI performance in Xbench, they have the same OS, the same hardware. Why is the throttling different between the two modes.

If what your saying is true. Both modes would have the same results. But it clearly not true as the xbench results are consistently different.

An analogy would be a weight scale that is off the mark. Say you want to weigh 2 objects, you cannot get the exact weight because the scale is off. However you know the difference between the 2 objects even if the scale is broken. In the this case Xbench is good at measuring the performance of HiDPI relative to non HiDPI on the same machine.


I don't give a damn about Xbench. Why? Because the the real world UI applications work differently. And the OS will throttle UI updates if they occur too quickly. So Xbench approach of triggering as many updates as the system can is ultimately flawed.

----------



Its hilarious that you of all people would call people wannabe programmers :rolleyes:
 
Last edited:
What code have you written?

Even if the OS throttles UI if they occur to quickly. Why the difference between the HiDPI and non HIDPI performance in Xbench, they have the same OS, the same hardware. Why is the throttling different between the two modes.

If what your saying is true. Both modes would have the same results. But it clearly not true as the xbench results are consistently different.

An analogy would be a weight scale that is off the mark. Say you want to weigh 2 objects, you cannot get the exact weight because the scale is off. However you know the difference between the 2 objects even if the scale is broken. In the this case Xbench is good at measuring the performance of HiDPI relative to non HiDPI on the same machine.
It's a software issue that CAN be fixed if Apple stop being lazy and upgrade the graphics drivers. Just wait till 10.11 which focuses on stability and performance. I will be here, laughing at you as this new OSX version performs stutter free while you desperately start backpedaling.
 
Considering that Windows 8 with its HiDPI settings works fine on 4K displays and even on the rMBP without any lag at all I'd say the problem is likely software optimisation.

For example scrolling on webpages is smoother in Safari than in Chrome on a Retina MacBook Pro when HiDPI is turned on. They get almost the same with HiDPI turned off.

I believe the problem is CPU overhead with draw calls. Simple explanation, anytime the GPU wants to draw something on screen it needs the CPU to direct it, the current API's they have are extremely thread limited with a lot of overhead.

Metal fixes this by reducing the amount of overhead and making it fully multithreaded. We're talking limits of 1.2 million draw calls a second on a mobile GPU to more than 11 million. Huge increases.

The GPU's we have are more than fast enough to handle a 4K display. They are bandwidth monsters designed exactly for this kind of workload, the issue is most definitely in the software frameworks Apple uses for running the desktop UI.

I think they can and will solve it eventually but they can't do it with cocoa level optimisations like more efficient lists for smoother in-app list scrolling. It needs to be a full graphics foundation rewrite right down to the window compositor. I feel they went a bit hacky when Retina first came out to maintain compatibility with non-retina ready software and that lack of fine grained optimisation has come back to bite.
 
Considering that Windows 8 with its HiDPI settings works fine on 4K displays and even on the rMBP without any lag at all I'd say the problem is likely software optimisation.

For example scrolling on webpages is smoother in Safari than in Chrome on a Retina MacBook Pro when HiDPI is turned on. They get almost the same with HiDPI turned off.

I believe the problem is CPU overhead with draw calls. Simple explanation, anytime the GPU wants to draw something on screen it needs the CPU to direct it, the current API's they have are extremely thread limited with a lot of overhead.

Metal fixes this by reducing the amount of overhead and making it fully multithreaded. We're talking limits of 1.2 million draw calls a second on a mobile GPU to more than 11 million. Huge increases.

The GPU's we have are more than fast enough to handle a 4K display. They are bandwidth monsters designed exactly for this kind of workload, the issue is most definitely in the software frameworks Apple uses for running the desktop UI.

I think they can and will solve it eventually but they can't do it with cocoa level optimisations like more efficient lists for smoother in-app list scrolling. It needs to be a full graphics foundation rewrite right down to the window compositor. I feel they went a bit hacky when Retina first came out to maintain compatibility with non-retina ready software and that lack of fine grained optimisation has come back to bite.

This sounds like the most likely cause. I really do hope Apple fix it as i would love a retina screen but i cant handle frame drops/ui lag. The moment Apple fix it il be getting a 13" rMBP.
 
MacBook Pro LAGtina i really hate the bad optimization of UI speed in OS X.

I'm sure Apple have knowledge this problem.

are the engineers working or just making money? :mad:
 
First of all my post is a rant that lag on the rMBP exists when using HiDPI resolution. The current rMBP are power enough to handle HiDPI but with lag.

If you can't understand that than maybe you can't perceive lag.

As for proof, just run a xbench with the same resolution using HiDPI and not using HiDPI. The non HiDPI will perform at least 40% faster on graphics test.

Attached xbench graphic results running in HiDPI and non HiDPI on 10.10.3.
i can confirm this. i have lag when i'm tryin to use netbeans, the lag is very noticeable when scrolling and typing!!!!.....btw i'm on my mbpr 13" 2015. i thought this machine could handle netbeans very well but it's not!!!.
so, how can i get 1440x900 without hi-dpi on my mbpr? what software do you use?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.