Thanks for the info. OK I figured out instead of using fill_parent in width and height of my main LinearLayouts, I instead hardcode the HVGA size of 320 x 480px the aspect ratio is ok. The game is looking much better in compatible mode.
Except seems like in compatible mode gravity of center_vertically is not working correctly? The container of the textview I am trying to center vertically is in a LinearLayout with height = 480px however it is still centering within the WVGA screen height. What can I do to fix this? I have to rely on compatible mode unfortunately as there is too many graphics to redraw for different resolutions and no money to pay the designer :D On Nov 22, 7:16 pm, Dianne Hackborn <hack...@android.com> wrote: > On Sat, Nov 21, 2009 at 4:26 PM, Mark Murphy <mmur...@commonsware.com>wrote: > > > > > "DROID has been optimized to display wide-screen multimedia (movie) > > content at its native aspect ratio of 16/9. This is different from the > > HVGA aspect ratio of 3/2, which is the traditional computer screen > > format. What this means is that when content is scaled up to "full > > screen", the horizontal (X*1.5) and vertical (Y*1.77) scaling factors > > are different. As a result, when displaying the same bitmap as a full > > screen background, round circles can appear as ovals, and squares are > > elongated to rectangles." > > >http://developer.motorola.com/docstools/library/Support_for_Multiple_... > > > I have no reason to believe this is DROID-specific, but rather is how > > Android scales things in WVGA800/WVGA854, when you do not supply your > > own pre-scaled resources. > > I think what they are trying to say is correct, but probably misleading. > > First, scaling is only done based on density, and does NOT change aspect > ratio. If you are on a high density device, and your assets are medium > density, they will be scaled by 1.5 in both width and height, period, end of > story. > > What this Motorola doc is describing is what I would consider a special > case. If you make a layout that is fill parent for both width and height, > then on a WVGA of course it will be taller than on HVGA because the screen > you are filling is taller. Now if you set a drawable as its background, the > View class draws its background by simply stretching the drawable to fill > its contents, so your bitmap will be stretched to fill whatever aspect ratio > your layout has ended up being. This is just a matter of accounting for the > screen being different sizes and designing your layout to adjust > accordingly. > > > You cannot control the aspect ratio, as that is dictated by the physical > > parameters of the screen. AFAIK, there is no Android equivalent of > > "letterbox" that would put black bars on either side of your app and > > give you a smaller virtual screen with 3/2 aspect ratio. > > We actually do a "postage stamp" for apps on large screens, since we found > that a significant number of them broke when given so much extra space. > However, the vast majority of existing apps work reasonably well when > presented with a WVGA screen, so rather than cause all of the existing ones > to not be able to use that space, we decided to not provide compatibility > for that and live with the small handful that did have significant problems. > > But for someone writing an app today, this is fairly irrelevant, because if > your app really can't use anything more than an HVGA screen then you really > just need to design your layout to center or whatever you want your content > in whatever screen you are running on. > > > Also in my layout I am positioning some items using pixel positions. > > > Should I convert these to dpi? > > If you mean dip (density-independent pixels), perhaps. It depends on > > what the pixels represent. There is no hard-and-fast rule. > > But the vast majority of time, yes, you do want to use dpis. > > However! The original post showed that the app was actually saying it can't > deal with densities. This means the system will emulate a medium density > screen on whatever density the device is, so 1 px == 1 dip. However, you > really should not be saying that you don't support densities -- there are > artifacts that can happen when doing this, such as font metrics not being > quite right. > > If you are writing an app today, you really want to not put yourself in > compatibility mode, and just write the app correctly. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
