[Asus  Eee Pad Transformer Prime] Dianne Hackborn:
In theory games could have an option to set the resolution you play at, just like you can on PC games. It would be a little different from the PC in that the final lower-resolution game rendering would need to be up-scaled to the native screen resolution when finally shown.

Fortunately this can be fairly easy to do -- if you have your game UI in a SurfaceView, you can just use SurfaceHolder.setFixedSize to set the size you want your game to draw at, and the platform will take care of up-scaling it as needed... in on the devices we are talking about, in most cases there is 0 cost to this up-scaling since the game surface should be running in a hardware overlay.

Unfortunately, the chance of many games actually going this far is probably low. :p

---------- Post added at 09:54 AM ---------- Previous post was at 09:46 AM ----------

Actually the current density on these tablets is relatively low (160dpi or less) relative to what we are getting used to on our phones. They definitely aren't at the point where they are the same as looking at a printed piece of paper. There is a lot can be gained still by increasing density... though there is a very good chance that comes at the expense of the hardware not being able to do 60fps drawing for the regular UI.

It doesn't make sense to compare this with a TV, since you sit so much farther away from television. Even so, personally on my 50" I can definitely tell the difference between 720p and 1080p, because I am sitting close enough to it.

And really, even phone screens going above 300dpi may be useful. Given that we still feel the need to use anti-aliasing on fonts and such even at that density, there is probably something to be gained by going a bit higher.

---------- Post added at 10:02 AM ---------- Previous post was at 09:54 AM ----------

If you are just taking the numbers reported by DisplayMetrics, don't think they mean anything. There is no way for the platform to compute those; they are just set by the device manufacturer to whatever they want when they make the device and configure the Android platform. In theory they should be the real DPI of the screen, but in practice they are often wrong (often significantly wrong).

The only sure way to determine this is to take the resolution and measure the screen size and do the computation yourself.

---------- Post added at 10:20 AM ---------- Previous post was at 10:02 AM ----------

Wow, that is *really* misleading.

It is true that Android platform development is done against specific devices.

It is so very not true that each release is "optimized" for a specific chipset. Yes, there are optimizations done in the platform as needed to make it run well, and whatever chipset it is being development on will be the guide for what those are.

However, base ICS is being run on not only Galaxy Nexus, but also Nexus S (which is also a TI chipset), and Xoom. ICS is also just an evolution of HC, and HC was already optimized for Tegra through the work done for Xoom. It is not being de-optimized for Tegra because there are now further optimizations for some specific TI issues.

Further, there is very little about a particular release that would prevent it from running well on a different chipset than it was developed on. Most of the performance issues are related to the drivers for the chipset, so a company with good software engineers and understanding of Android is perfectly capable of developing high performance drivers (and as far as I can tell, nVidia has both those things).

Beyond that, Android *is* an open-source platform, so if there is some implementation in the framework that causes unexpected performance issues on a particular chipset, the vendor can fix this as well (and even contribute their fix back to the mainline platform if they want). Not only can this happen, but it does.

Now there are certainly some kinds of "optimizations" that can't be done outside of the mainline platform, generally if they may have an impact on applications. This shouldn't be common for chipset optimizations, but it can happen. For example, the SGX GPU used by TI has a deferred rendering model that can cause a big performance hit on certain operations which cause it to have to wait for the current rendering to complete before proceeding. This is why ICS removed the widespread use of fades in the UI (truncating text and at the top and bottom of scrollable regions), because to implement this you hit these really bad cases on SGX. Again this is not a common situation, but it can happen. And it is not relevant for Tegra since Android already runs well on Tegra.

Wow sure doesn't sound like there is any bias here. ;)