Joe Levi:
a cross-discipline, multi-dimensional problem solver who thinks outside the box – but within reality™

Why is the Palm Treo 320×320 and the Windows Treo 240×240?

A question that is asked frequently about Windows Mobile devices is why they’re “lower resolution” than their Palm counter parts, particularly the Treo P (320×320) and Treo W (240×240) models.

The root of the screen resolution debate is less about what the “OS can support”, or what the “screen can support” than it is about where the two OS’s (Windows Mobile versus Palm) get their native screen resolutions from.

Windows Mobile (yes, even all the way pack to Handheld PCs and Palm PC’s, remember those?) has always been based around the VGA model (640×480) or some even ratio of it.

Current Pocket PCs are (mainly) qVGA (quarter VGA) 240×320, with some at 240×240. How does one get this ratio?

Take VGA (640×480), rotate it 90 degrees (480×640) and take 1/4 of the pixels (half of each number). You end up with 240×320.

Now, Microsoft decided early on to offer a SIP (Soft Input Panel) rather than Palm’s “scratch pad”. This difference meant that, unlike Palm’s square display, Microsoft could choose to free up the real-estate occupied by the SIP when it was not in use. Good move.

But that left Microsoft with a rectangular screen. They went with that. They built icons and other UI around the qVGA model. When square screens came around, they simply truncated the bottom of the screen, it was still 240 wide, so all the icons and UI still worked, but it wasn’t as tall, therefore scrollbars might be seen more often — but the icons didn’t change.

Then came TRUE VGA (again, rotated 90 degrees) — 480×640. This required Microsoft (an application providers) to create sets of bigger icons for the bigger display. Any applications that weren’t “VGA Aware” simply had their icons “doubled” — and they looked pretty blurry, but it was easy to simply double the pixels.

So what happened to 320×320? Well, since 320 is 1.5 times larger than 240, and 1.5 times smaller than 480, to handle this resolution Microsoft and all application providers would have to make another icon set, and for those that weren’t “320 aware”, how do you make a pixel 1.5 times as big as it was, or 1.5 times as small? It just doesn’t work out.

So, you’ll probably NEVER see a 320×320 Windows Mobile device… it’s much more likely that you’ll see a 480×480 device (since that’s a truncated VGA screen and would use the “VGA Aware” icon set).

Why don’t we see 480×480 screens today? They’re simply too expensive right now.

So… hopefully that didn’t confuse y’all too much. Questions?


You may also like...

2 Responses

  1. Randy Royer says:

    Our company has an app that uses a remote desktop (or terminal services) session on a wireless HHD (running Win CE or Mobile) to display a single column VB form. Our form has a resizer on it (It can be “dragged” larger or smaller on the screen). On a regular large monitor or on a 320×320 HHD remote screen – the form behaves fine. You can bring it up and resize it and it saves the last size it was modified to. HOWEVER when the same user accesses the resized form on a ¼ VGA HHD device (240×320) with the same OS (CE or Mobile) -regardless of the saved size- the form loads at full size and the bottom 2 fields (which the user need to see) get truncated off. Note that if you then access the form on the 320×320 device the “postage stamp size” resized window will display fine. Do you know why the resizer does not work on the smaller pixel screen? Do you have any ideas for us?

  2. Joe says:


    The difficulty that you describe seems mostly to do with the application running on terminal services rather than as a “native application” on the Pocket PC.

    Doing so obviously has its advantages (and disadvantages).

    I’d begin by looking at the resizer that you mentioned. Does it “sniff” the client’s screen resolution and dynamically re-size? If so, can you add a label to the form that displays the client’s detected resolution? You might find that the TSAC (on the Pocket PC) is reporting it’s desktop incorrectly, and the sizer is then behaving “properly” based on the incorrect information.

    Then again, it may be something else.

    An alternative option might be deploying a web service that a custom Pocket PC / SmartPhone application could tie into, thereby allowing you to code to a specific resolution, but still allow sharing of a common data source.

    (BTW: I attempted to email you at the address you provided, but it bounced. I’m hoping you come back to this article and read my reply.)

Leave a Reply