It won't make a difference to performance unless you're on some platform that can only output video signals in some restricted set of resolutions.

e.g. a hypothetical current gen console might be built to always output at 720p or 1080p, so if you internally use a lower resolution, then you have to explicitly pay the cost of resizing your framebuffer to 720p. However, these systems might also provide hardware support to assist in this operation... Nonetheless, you will burn a fraction of a millisecond performing the scaling.

If we take what he's saying less literally, and replace "performance" with "latency", he might be slightly more true, at least when displaying on a television.

Some displays will be optimized specifically for their native resolutions only. If you send them a signal for a different resolution, they might be forced to internally re-scale the signal to match their native resolution. This operation, when done by a television, often takes one frame's worth of time -- i.e. so a 60Hz signal will have 16.6ms of latency added to it if rescaling is performed inside the TV.

Technically, there is no performance penalty, because this rescaling happens "for free" in parallel, inside the television... but your overall input latency is hugely affected.

Modern HDTV's (especially early or cheap ones) are often offenders in this category -- sometimes playing current gen console games that are 720p on a 1080p TV will result in an extra 16.6ms of latency, which is rediculous

However, there's no way to query this. Some TV's wont add any extra latency depending on the resolution. Some will add latency if you don't output a "standard" signal. Some will add latency if you don't output a specific signal (e.g. 1080p only). Some TV's will always add a huge amount of latency for no good reason!

The best rule of thumb I can think of here would be to prefer outputting at the monitors maximum supported resolution (which should be it's native resolution).

The best rule of thumb I can think of here would be to prefer outputting at the monitors maximum supported resolution (which should be it's native resolution).

Even that's not always perfect, though. I've run into quite a few LCD projectors, for instance, that "support" higher resolutions than they can actually display, and actually seem to downsample the input signal. Worse yet, the downsampling was very crude, but just "good" enough that it was obvious that it was supposed to be a "feature."

Asking him about it just got the response of "well, it only happens for more advanced graphics algorithms."

I'd ask him for an example of such "advanced graphics algorithms".

Frankly it sounds like he doesn't know what he's talking about, or accidentally said something he didn't mean and has low enough self-esteem that he can't bring himself to back out of it.

Precisely. This sounds exactly like the kind of theoretical nonsense academics sometimes come out with. If it was the case then the API documentation would be shouting about it, the hardware vendors would be shouting about it, John Carmack would be tweeting about it, Johan Andersson would be blogging about it.

The fact that those who define pretty basic stuff such as how APIs and hardware actually work, the fact that those who have a track record of actually using this stuff in the field for real programs that real people use, are not doing so is evidence enough. It's nonsense.

If I'm not mistaken, most LCDs today have built-in hardware to scale the incoming image to the monitor's native resolution.

Most, but not all by any stretch (pun unintended).

I tend to buy those quad-def IPS monitors from S. Korea, and they explicitly do not included a scaler. Downside, it won't work as a TV, but on the upside you cut down the lag, and desktop GPU's tend to do pretty well at scaling anyway.