That's very interesting Dianne, and thanks for taking the time to
weigh in.
What you are saying makes sense too because the physical size of the
screens on Android devices differ. At the very least I expect that
each device does the calculations properly when displaying widgets.
Or, is that assumption bad too?
So, Phil is right too that my numbers would be off by some margin.
I wish the OEMs would make the information from their certification
and test results documents available to the public ... have you seen
any talk about that?
That information would help a lot in identifying different device
behavior for doing QA. Nothing worse than having a tester try to line
up screen captures for pixel perfect matches during a test and having
to explain that "it's just the device" .... at least not without some
hard data.
Richard
On Jan 12, 12:33 pm, Dianne Hackborn <hack...@android.com> wrote:
> The density and densityDpi is an abstract density bucket the device
> manufacturer has decided makes sense for their UI to run in. This is what
> is used to evaluate things like "dp" units and select and scale bitmaps from
> resources.
>
> The xdpi and ydpi are supposed to be the real DPI of the screen... though
> as you've seen, many devices don't set it correctly. :( This is our fault,
> it isn't actually used anywhere in the platform, so people don't realize
> they have a bad value, and we haven't had a CTS test to try to make sure it
> is sane (it's not clear how that test should work). Worse, we shipping the
> original Droid with a graphics driver that reports the wrong value here...
> in fact that reported that same damnable 96.
>
> Unfortunately, I don't have a good solution if you want to get the real
> exactly screen dots per inch. One thing you could do is compare xdpi/ydpi
> with densityDpi and if they are significantly far apart, assume the values
> are bad and just fall back on densityDpi as an approximation. Be careful on
> this, because a correctly working device may have densityDpi fairly
> different than the real dpi -- for example the Samsung TAB uses high density
> even though its screen's really density is a fair amount lower than 240.
>
> On Wed, Jan 12, 2011 at 11:31 AM, Phil Endecott <
>
>
>
>
>
> spam_from_goo...@chezphil.org> wrote:
> > Hi Richard,
>
> > On Jan 12, 6:54 pm, Richard Schilling <richard.rootwirel...@gmail.com>
> > wrote:
> > > Did you try fetching the scale that will allow you to convert from DPI
> > > to actual screen pixels? I found this very reliable:
>
> > > final scale =
> > > getContext().getResources().getDisplayMetrics().density;
>
> > The description of that says:
>
> > "on a 160dpi screen this density value will be 1; on a 120 dpi
> > screen
> > it would be .75; etc."
>
> > > Then multiply scale by one inch of pixels in DPI resolution (depending
> > > on the screen you're on) - 120, 160, 240, 320.
>
> > > This API call ...
>
> > > int densityDpi =
> > > getContext().getResources().getDisplayMetrics().densityDpi;
>
> > > will tell you the density of the screen you're on.
>
> > Approximately.
>
> > > So, this will tell you how many screen pixels equate to an inch.
>
> > I'm not at all sure that it does.
>
> > > Then
> > > you can use that to lay out your ruler markings:
> > > int pxPerInch = 340; // default value - note it's a new density
> > > in API version 9.
>
> > > switch(densityDpi){
> > > case DisplayMetrics.DENSITY_LOW:
> > > pxPerInch = 120 * scale;
> > > break;
> > > case DisplayMetrics.DENSITY_MEDIUM:
> > > pxPerInch = 160 * scale;
> > > break;
> > > case DisplayMetrics.DENSITY_HIGH:
> > > pxPerInch = 240 * scale;
> > > break;
> > > }
>
> > Note that the values of those constants DENSITY_* are their numeric
> > values, so there is no need for the case statement; you can just
> > write:
>
> > pxPerInch = densityDpi * scale;
>
> > However, I really don't think that does what you believe it does. I
> > think that densityDpi reliably gives the approximate dpi, and density
> > just gives densityDpi/160. Multiplying them together doesn't do
> > anything useful. But I could be wrong!
>
> > Thanks, Phil.
>
> > --
> > 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<android-developers%2Bunsubs
> > cr...@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> 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
