Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: size.Event pt values appear incorrect on moto G 2nd gen #13366

Closed
dskinner opened this issue Nov 23, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@dskinner
Copy link
Member

commented Nov 23, 2015

As I understand it, 72pt == 1 inch. The size.Event generated on a moto G 2nd gen is as follows:

{WidthPx:720 HeightPx:1184 WidthPt:162.00pt HeightPt:266.40pt PixelsPerPt:4.4444447 Orientation:1}

This suggests the following measurements: 2.25in. x 3.7in.

The actual measurements of the device: 2.5in. x 4.375in. (5in. diagonal)

@rsc rsc changed the title mobile: size.Event pt values appear incorrect on moto G 2nd gen x/mobile: size.Event pt values appear incorrect on moto G 2nd gen Dec 28, 2015

@rsc rsc added this to the Unreleased milestone Dec 28, 2015

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2015

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2016

Are the actual device measurements you list the current drawable area? (That is, if you make the screen red, does the red area have those measurements?)

I don't know if it applies here, but there is a general problem with mobile devices that some scaling happens long after all of the drawing is done and the app is not informed (for example, the iPhone 6 Plus, with a 1.15 multiplier).

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 11, 2016

I'm not aware of that sort of scaling done on Android. The height reported is not the full pixel height of the device but that is normal on android as the system will subtract height of status bar and software device buttons (if they exist) before fulfilling a height request to an app.

The reported width on the other hand seemed enough to suggest there is an issue though. The device has precisely 720px width which is correct as reported but the pt value reported doesn't make sense.

I was going to dig into this eventually to implement density-independent-pixels and the first thing I'd like to check is pt value reported by the java api. At the very least, that result should match the gomobile result, even if incorrect.

I've also never worked with pt values outside of some graphic software so my expectations may simply be wrong as well.

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 11, 2016

For reference, there doesn't actually appear to be a java api to report screen dimensions in pt so I ran the following on device:

DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
Log.d("@@@", "width in px: " + dm.widthPixels);

for (float n = 162; n <= 180; n += 0.5) {
  float v = TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, n, dm);
  Log.d("@@@", n + "pt: " + v);
}

162pt is what's reported by gomobile. 180pt is what I'd expect for 72ppi. Here's the results of the for-loop:

width in px: 720
162.0pt: 663.6758
...
175.5pt: 718.9821
176.0pt: 721.0305
...
180.0pt: 737.41754

This only serves to confuse the matter as ppi appears not to be 72.

I created a layout as follows:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="horizontal">

    <View
        android:layout_width="719px"
        android:layout_height="20dp"
        android:background="#ff0000" />
    <View
        android:layout_width="1px"
        android:layout_height="20dp"
        android:background="#0000ff" />

</LinearLayout>

This does what is expected, filling the entire width of the screen with a single pixel width blue line at the end. Here's a screenshot (I framed screenshot to make more apparent before cropping).

device-2016-01-11-135249

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 11, 2016

One other item of note, the "actual dimensions" I provided were derived from a tape measure. Using a ppi calculator suggests the actual dimensions are slightly smaller, 4.36" × 2.45" with a ppi of 293.72 PPI which matches the devices spec sheet of ~= 294 ppi.

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 29, 2016

Looked into this, issue is here: https://github.com/golang/mobile/blob/master/app/android.go#L220

Dividing the density by 72 isn't sufficient for determining PixelsPerPt, this would only give a very rough approximation that's not suitable for use.

There is a java api intended to provide this: http://developer.android.com/reference/android/util/DisplayMetrics.html#xdpi

I could not find anything in NDK for this. Regardless, at least five years ago the xdpi and ydpi were considered unreliable as hardware vendors shipped with incorrect values but no one notices since these values are not used anywhere in the system. So, while a jni binding to retrieve the value would fix this, it's not clear if its going to be reported correctly across all devices in use today.

The mobile/geom package sheds some light on the intention here but it looks to be impractical to provide actual typographical point values on android.

160dp is meant to equal sort-of-an-inch and should probably be the basis for what is provided in the size event on android (caveat emptor). This can be used to establish the PixelsPerPt in size.Event and the WidthPt and HeightPt can be filled appropriately.

The solution is not aggreable with being exact, but it doesn't appear exact is possible across all android devices unless positive evidence can be turned up regarding DisplayMetrics.xdpi and ydpi.

If this solution sounds ok, I can put something together.

/cc @nigeltao

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 29, 2016

every use of ppi in my last comment was meant to be PixelsPerPt (fixed), sorry for the confusion

@nigeltao

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2016

Sounds OK, but I'd give @crawshaw the definitive say, since he wrote the original Go mobile code wrt Android DPI.

If you do put something together, please add a summary of your last (substantial) comment above as a comment in the code too. It might also help to link to whatever seems most definitive about "how to determine Android DPI in practice". A quick query to my favorite search engine turned up http://developer.android.com/guide/practices/screens_support.html#dips-pels but you might know of better resources.

It might also be nice to check in an example program, or modify the example/basic program, to draw a centered square that is 1 inch by 1 inch under the existing green triangle that follows touches. Maybe @crawshaw would have a better idea of a good DPI example.

@dskinner

This comment has been minimized.

Copy link
Member Author

commented Jan 30, 2016

The table here is a good example of how this works: https://www.google.com/design/spec/layout/units-measurements.html#units-measurements-density-independent-pixels-dp-

The footnote suggests a device with 1.5 inch width and doing the math for 160dp is an example of how you'd end up at exactly 1 inch. But, consider the same table for a device with 2 inch width and then you'd end up at 1.33 inches.

On my 2.45" width device I referenced in the original issue, a 1 inch square would be 1.225 inches as it falls into the 320 bucket density. A 2" width device with the same resolution would also fall into the 320 bucket density and a 1" square would actually be 1".

The density bucket is also apt to tampering by the hardware vendor.

So, for clarification, the gomobile example of drawing a 1" square wouldn't necessarily be 1" but it would look consistent across similar devices.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 12, 2016

CL https://golang.org/cl/24865 mentions this issue.

@golang golang locked and limited conversation to collaborators Aug 4, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.