Apple may want to update how it scales (larger text vs more space)

[Xcelerate]

My RMBP hasn't shipped yet, but from what I read from other people, if you select a different scaling mode (larger text vs more space), I think there is a problem -- in both performance and quality.

Here's why. Say you want the "equivalent workspace" of 1920x1200. So it renders everything at 3840x2400 and then resamples it down to 2880x1800. But when the graphics were calculated at 3840x2400, the anti-aliasing (for text and vector images) was already computed to be optimal at this setting -- in order to be the clearest, these calculations must take place at the final viewing resolution. Downsampling "unoptimizes" this. Not to mention you have extra needless calculations.

And from the other end of the spectrum, if you select the "larger text", the Macbook is creating a smaller rendering and then upscaling it to 2880x1800. This won't look very good either.

The ideal way to do it would be to simply program all vector/text rendering in natively for a given scaling factor. So a 1920x1200 "workspace" has a text/graphic that is 75% of the area of the same text/graphic in a 1440x900 "workspace" for the same screen size. So just render it this way.

Here's an example. I rendered antialiased text at three font sizes: 36, 72, and 144 pt. Then I upsampled the first font and downsampled the last font to 72 pt size. You can see that neither look as good as the native font. The downsampled font isn't too bad looking, but it's extra processing power that isn't necessary.

 

[7even]

I have yet to try working with graphics on the new screen (have it on order), but I think that most people will be hard-pressed to find a difference between the downsampled and native versions. Yes, it's not optimal, but it's better than upscaling. (The difference might be more visible if you redo the same image in PNG format).

 

[bhtooefr]

Believe this is the image you're looking for: http://bhtooefr.org/images/AnandRetinaScaled/1920.png

(Scaled down to 2880x1800.)

Compare to http://bhtooefr.org/images/AnandRetinaScaled/1440.png (that pic is actually not scaled at all, it's just Anand's 1440/2880 screenshot as-is).

It's not quite as good, but most people won't be able to notice the difference - the thing is retina at 15.6" away for someone with 20/20 vision.

 

[Stetrain]

Believe this is the image you're looking for: http://bhtooefr.org/images/AnandRetinaScaled/1920.png

(Scaled down to 2880x1800.)

Compare to http://bhtooefr.org/images/AnandRetinaScaled/1440.png (that pic is actually not scaled at all, it's just Anand's 1440/2880 screenshot as-is).

It's not quite as good, but most people won't be able to notice the difference - the thing is retina at 15.6" away for someone with 20/20 vision.

Thanks for providing those, very nice reference. You can see the difference for sure, especially since unless you're on a 220dpi display everything is magnified, but definitely usable.

 

[bhtooefr]

Thanks for providing those, very nice reference. You can see the difference for sure, especially since unless you're on a 220dpi display everything is magnified, but definitely usable.

I really should scale these to be the correct size for 264 and 326 ppi, for viewing on an iDevice with retina.

I've just been looking at these shots on my 168 and 171 ppi Windows machines, though. I have been playing with downscaling shots to get the size to where it'd be if I were on a MBPR, although at a loss of quality.

 

[Xcelerate]

Hold on, who gave me a thumbs-down, and why?

Maybe I'm being misunderstood. Resampling is an expensive operation. If Apple is using something like bicubic or lanczos3 60 times a second, that's a lot of processing power. I'm saying if they render vector GUI elements at native resolution instead of at a different one and then rescale it, that will improve its appearance, save processing power, and conserve battery. Unless I'm completely misunderstanding what AnandTech is saying.

Check out this image:

http://images.anandtech.com/galleries/2078/Screen%20Shot%202012-06-11%20at%204.35.25%20PM.png

It's rendered at 2048x1280 (you can verify that in Inspector or Firebug). Which means it must be UPSAMPLED to 2880x1800 -- it must be in order to be displayed at all (unless you want black bars on the side of the screen). So we go from 220.5 DPI to 156.8 DPI in optical resolution. Why? There's no benefit to this -- visually, computationally, or from a power consumption standpoint. Can someone give me any benefit other than being slightly easier to program? Or clarify if I am misunderstanding the article?

 

[Stetrain]

I'm saying if they render vector GUI elements at native resolution instead of at a different one and then rescale it, that will improve its appearance (slightly), save processing power, and conserve battery.

As far as I know, no modern consumer OS has a fully vectorized GUI.

The only thing Apple could realistically do better would be to do scaling of each individual image on screen down from maximum size to the size it needs to be displayed on screen. Fully vectorized fonts could be displayed then without scaling.

I think the issue with using this method is the potential issues with application compatibility. With the current method, UIs only have to be able to know how to draw themselves at two scales: 1x and 2x.

If you've followed HiDPI mode's state in OSX at all you will know that it was a long road to even get this simplistic setup working. In early versions of Lion, even simple apps like TextEdit had glitches when you enabled the 2x scale HiDPI mode:

http://arstechnica.com/apple/2011/07/mac-os-x-10-7/14/

 

[Xcelerate]

As far as I know, no modern consumer OS has a fully vectorized GUI.

The only thing Apple could realistically do better would be to do scaling of each individual image on screen down from maximum size to the size it needs to be displayed on screen. Fully vectorized fonts could be displayed then without scaling.

I think the issue with using this method is the potential issues with application compatibility. With the current method, UIs only have to be able to know how to draw themselves at two scales: 1x and 2x.

Hmm... okay I think I see where you're going with this. You're saying the reason they are doing this rescaling is so, to an application, the OS resolution will appear to be 1024x600, 1440x900, 1680x1050, 1920x1200, etc... all the common ones that are currently used in laptops. Then when rescaled, it will be the correct (as measurable with a ruler) size on the screen. That makes sense.

I know Apple stores their icons at 1024x1024 now (some Macrumors article). They probably do something similar with raster UI elements. I don't see why they couldn't still scale these components directly these down to their final resolution instead of going below that resolution and then upsampling. Any running applications would remain untouched but the rest of the OS would be 64 DPI sharper (for the 1024x600 case).

EDIT: Okay, I saw your edit. So regarding my last paragraph, you think eventually Apple is headed for something like this, but with everything else released at the moment it's not of too much importance?

 

[Stetrain]

EDIT: Okay, I saw your edit. So regarding my last paragraph, you think eventually Apple is headed for something like this, but with everything else released at the moment it's not of too much importance?

Probably eventually, but I think that's still a long ways away. Being able to tell an app to draw itself at arbitrary scale sizes and have it always look good is a much bigger challenge than simply supporting 1x and 2x scales.

It's the same reason that both the iPhone and the iPad were updated with exactly 2x the DPI.

OS developers have been touting "True resolution independence!" as a future feature for many years, and I haven't seen it really happen yet. The closest I've seen to making this really happen is web based development using 100% CSS with no images. Still it isn't guaranteed to always look right on every screen size 100% of the time.

 

[Xcelerate]

Okay, thanks! I appreciate your thorough response.

 

[Xcelerate]

So I thought it would be prudent to bump this thread. My concerns about performance at high resolution and scaling down were before threads started appearing with the lag problem. From what some people have posted, it appears this problem occurs mainly on resolutions higher than 2880x1800 that are scaled down, as I thought there might be. Like I said, resampling is an expensive operation.

I see why they did it, but I hope Apple can update to my suggested method at some point.

 

[MikhailT]

So I thought it would be prudent to bump this thread. My concerns about performance at high resolution and scaling down were before threads started appearing with the lag problem. From what some people have posted, it appears this problem occurs mainly on resolutions higher than 2880x1800 that are scaled down, as I thought there might be. Like I said, resampling is an expensive operation.

I see why they did it, but I hope Apple can update to my suggested method at some point.

Except the most common complaint about the lags is in the scrolling of Safari which is due to bad graphic drivers or rendering engine issue. The same people who tested the same site in Chrome confirmed there were no lags. In addition, some reports were of un-patched Macs in the Apple Stores whereas just as many people confirmed there were no lags on their own personal MBP-RD.

Also, many people confirmed the lags were happening across all resolutions, including the double-pixel one, so it's not related to your theory.

Apple've already released a few updates and will continue to update to improve and optimize the OS to handle this situation better. This is a first-gen model with a new display, and like every other first-gen model, it's going to take several months before Apple fixed everything.

 

[Xcelerate]

Oh, really? Disregard me then