In order to bring some light into the issue I have now done what I should have for a long time - some systematic tests.
Test machine: retina MacBook Pro 2.3Ghz, 16GB RAM, 10.8.2 with Safari 6.0.2
Method: I switch resolutions while manually switching between HiDPI and 'normal mode' resolutions. I use safari (always maximised window) to display http://www.theverge.com, as this is a very difficult to render website and quickly scroll up-down along the whole height of the website. At the same time, I use QuartzDebug to monitor current UI refresh FPS. For each settings, I determine the most 'stable' FPS value (by eyeballing the QuartzDebug output). Now, I discard the lowest FPS value because the FPS will dip inadvertently at the point where the scrolling direction is changed - the UI will only redraw if there is a need to (e.g. picture has changed). For instance, as I am currently typing this the meter is at 10 FPS - because only a very small portion of the screen (the input form) must be updated infrequently (reflecting the speed with which I type) and 10 FPS is enough to provide smooth UI updates.
I didn't record the whole thing because a) I don't have any equipment to do this and b) it would be too much work. I threw this thing together during breakfast
Note: at high-res normal DPI modes, the rendered width of the website is much smaller than in the HiDPI mode. This is 'unfair' because it obviously reduces the workload compared to HiDPI modes Thus, for high-res modes I would do the test twice - once with the 'default' zoom settings (thevere occupies around 1/4 of the screen width on 2880x1800 mode and even less on 3840x1200 mode) and then zoomed in until theverge occupies around 1/2 screen width to make it comparable to what happens on HiDPI resolutions. For such resolution, I give two results in form of a (b), where a is the FPS when the width is normalised (zoomed in to 1/2 width) and b non-normalised (left as default)
Results:
HD 4000 GT 650M
2880x1800 20 (40) 20 (40)
3840x2400 10' (40) 10' (40)
1920x1200 50 45
1680x1050 (HiDPI) 25 30
1920x1200 (HiDPI) 25 30
All modes showed some micro-stutters, especially near the top part of the website, which uses complex tile layout. The stutter was very light at 1920x1200 (non HiDPI) and extremely noticeable at higher-res non HiDPI modes. I couldn't feel any difference between the micro-stutters in the tested HiDPI modes.
Discussion:
The benchmarks suggest that the HiDPI modes actually offer higher performance than the non-HiDPI modes with the same amount of pixels. Subjectively, the scrolling was very smooth at 1920x1200 (non HiDPI) and 'ok' on the HiDPI modes (save for some micro-stutter). It was really bad on the higher-res non-DPI modes.
On HiDPI modes, the results were better for the 650M, subjectively I couldn't tell any difference. Funny result: the HD 4000 actually appears to be faster in 1920x1200 (non-HiDPI) than the 650M. Could this have something to do with RAM access? I.e. HD 4000 can directly use system RAM as texture data while 650M has first to copy them to VRAM.
Also, take these results with grain of salt because the performance is not really consistent. I am also not sure how reliably the gfxCardStatus works for switching. Safari performance seems to degrade over time, so i hat to relaunch it several times. A more reliable benchmark would be to repeat the experiments multiple times and use proper statistics to analyse the FPS.
Test machine: retina MacBook Pro 2.3Ghz, 16GB RAM, 10.8.2 with Safari 6.0.2
Method: I switch resolutions while manually switching between HiDPI and 'normal mode' resolutions. I use safari (always maximised window) to display http://www.theverge.com, as this is a very difficult to render website and quickly scroll up-down along the whole height of the website. At the same time, I use QuartzDebug to monitor current UI refresh FPS. For each settings, I determine the most 'stable' FPS value (by eyeballing the QuartzDebug output). Now, I discard the lowest FPS value because the FPS will dip inadvertently at the point where the scrolling direction is changed - the UI will only redraw if there is a need to (e.g. picture has changed). For instance, as I am currently typing this the meter is at 10 FPS - because only a very small portion of the screen (the input form) must be updated infrequently (reflecting the speed with which I type) and 10 FPS is enough to provide smooth UI updates.
I didn't record the whole thing because a) I don't have any equipment to do this and b) it would be too much work. I threw this thing together during breakfast
Note: at high-res normal DPI modes, the rendered width of the website is much smaller than in the HiDPI mode. This is 'unfair' because it obviously reduces the workload compared to HiDPI modes Thus, for high-res modes I would do the test twice - once with the 'default' zoom settings (thevere occupies around 1/4 of the screen width on 2880x1800 mode and even less on 3840x1200 mode) and then zoomed in until theverge occupies around 1/2 screen width to make it comparable to what happens on HiDPI resolutions. For such resolution, I give two results in form of a (b), where a is the FPS when the width is normalised (zoomed in to 1/2 width) and b non-normalised (left as default)
Results:
HD 4000 GT 650M
2880x1800 20 (40) 20 (40)
3840x2400 10' (40) 10' (40)
1920x1200 50 45
1680x1050 (HiDPI) 25 30
1920x1200 (HiDPI) 25 30
All modes showed some micro-stutters, especially near the top part of the website, which uses complex tile layout. The stutter was very light at 1920x1200 (non HiDPI) and extremely noticeable at higher-res non HiDPI modes. I couldn't feel any difference between the micro-stutters in the tested HiDPI modes.
Discussion:
The benchmarks suggest that the HiDPI modes actually offer higher performance than the non-HiDPI modes with the same amount of pixels. Subjectively, the scrolling was very smooth at 1920x1200 (non HiDPI) and 'ok' on the HiDPI modes (save for some micro-stutter). It was really bad on the higher-res non-DPI modes.
On HiDPI modes, the results were better for the 650M, subjectively I couldn't tell any difference. Funny result: the HD 4000 actually appears to be faster in 1920x1200 (non-HiDPI) than the 650M. Could this have something to do with RAM access? I.e. HD 4000 can directly use system RAM as texture data while 650M has first to copy them to VRAM.
Also, take these results with grain of salt because the performance is not really consistent. I am also not sure how reliably the gfxCardStatus works for switching. Safari performance seems to degrade over time, so i hat to relaunch it several times. A more reliable benchmark would be to repeat the experiments multiple times and use proper statistics to analyse the FPS.
Last edited: