I am a beginner in WP development with Monogame, and I want to develop a universal WP app (All devices which run under WP).
Can you give me the different screen's resolution and aspect ratio?
480 × 800, ratio 15:9, scale factor 1 — WVGA, the only one supported by WP7.x OS version
768 × 1280, ratio 15:9, scale factor 1.6 — WXGA
720 × 1280, ratio 16:9, scale factor 1.5 — 720p
1080 x 1920, ratio 16:9, scale factor 2.25 — 1080p
The resolution in “logical pixels” (after the scaling) is either 480×800 on 15:9 screens, or 480×853 on 16:9 screens.
Source.
Related
I am implementing a "ruler" feature to my app and it is critical that the ruler size/scale, in centimeters, is consistent across multiple devices. That is, 1 'tick' must be always equal to 1 centimenter. Howerver I have not found in any documentation a way to size components using real-world units (cm, inch) like you can do in CSS; Nor have I found a way to accurately get the screen size (in inches or cm) or DPI.
Is there a way to use cm/inches in React Native or get the REAL screen DPI?
1 inch = 160 dp (Always)
Note that 1 inch is ALWAYS 160dp, independent of screen size. A dp(density-independent pixels) is a physical distance of 1/160th of an inch.
React-Native uses dp(density-independent pixels) as the unit in styling.
So, if you write:
<View style={{ height: 160, width:160, backgroundColor: 'red }}>
</View>
This gives you a red block of 1 inch X 1 inch
Dimensions properties in react native are unitless, so those properties are not available in ReactNative. The best you can do is use PixelRatio's getPixelSizeForLayoutSize() which is documented here: https://reactnative.dev/docs/pixelratio#getpixelsizeforlayoutsize
You would need to also have the pixel density (dpi) for your solution, and the formula:
https://www.pixelto.net/px-to-cm-converter
You still might run into some weird situations where pixels are split in half and other rounding errors as you're trying to fit 1cm into tiny pixels on the screen that may not always equal to 1cm, due to physical limitations.
Using version Linux C++ 3.1.1-2802 version the SDK.
The descriptions of FaceDetectorMode::LARGE_FACES (To target faces occupying a large area) and FaceDetectorMode::SMALL_FACES (To target faces occupying a small area) are a bit vague/confusing.
By "large" is it, for instance, faces that occupy more than 30% of the image's area or between 50% and 80%, or a certain amount of pixels, or what?
Experimenting with PhotoDetector with the FaceDetectorMode::LARGE_FACES and an image that contains 1 face at multiple resolutions (720p, 480p, 240p) I've found that the by face can't occupy most of the image (more than around 30% of the image's width/height) and has to be a certain minimum size in pixels in order to be detected but I can't figure out the relationship.
The main difference in large face and small face mode is what is the minimum size of face they will detect. The image property of interest is the minimum image dimension:
Large face: find faces that are at least ~15% the min. image dimension
Small face: find faces that are at least ~4% the min. image dimension
Example: In a 640x480 image, 480 is the dimension of interest and that would work out to 72 (0.15 * 480) and 20 (0.04 * 480) pixels for large face mode and small face mode respectively.
The reason there are two modes is that we've tuned each mode for an accuracy & speed tradeoff that works best for each. Small faces for image collections. Large faces for a person in-front of a camera.
Cocoa drawing sizes (widths & heights) are specified in points which are defined as follows in the OS X Cocoa Drawing Guide documentation:
"A single point is equivalent to 1/72 of an inch"
I understand from this that a point is a physical distance. So if my screen is 20 inches wide (for example) I would have 20 x 72 = 1440 points of horizontal width in points to work with. In other words, a point is independent of the resolution of the device.
This does not seem to be so...
A simple cocoa application using window width as a test shows that:
1) when my resolution is set to 1680x1050 it will take a width of 1680 points to span the width of the screen
2) similarly, if I change my resolution to 2560x1440 it will take a window width of 2560 points to span the width of the screen
Also confusing (in a contradictory way) is the statement made in the High Resolution Guidelines Apple Document that:
Each point in user space is backed by four pixels
The above tests seem to indicate that I have a user space of 1680x1050 when my display resolution is set to 1680x1050. If there are 4 pixels per user point then this would point to an effective "real" resolution of 2 times (1680x1050) = 3360x2100 which is more than the native resolution my 13 inch retina macbook pro of 2560x1600.
Points are an abstract, virtual coordinate system. The intent is that you usually design and write drawing code to work in points and that will be roughly consistent to human vision, compensating for different physical display pixel densities and the usual distance between the display and the user's eyes.
Points do not have a reliable relationship to either physical distance units (inches, centimeters, etc.) or physical display pixels.
For screen displays, there are at least three different measurements. For example, the screen of a Retina MacBook Pro has 2880x1800 physical pixels. In the default mode, that's mapped to 1440x900 points, so each point is a 2x2-pixel square. That's why a window on such a system has the same visual size as the same window on a non-Retina MacBook Pro with a screen with 1440x900 physical pixels mapped to 1440x900 points. The window is measured in points and so takes up the same portion of the screen real estate. However, on the Retina display, there are more pixels allowing for finer detail.
However, there is another layer of complexity possible. You can configure that Retina system to display more content on the screen at the cost of some of the detail. You can select a display mode of 1920x1200 points. In that mode, the rendering is done to a backbuffer of 3840x2400 pixels. That allows for rendering at a higher level of detail but keeps the math simple; points are still mapped to 2x2-pixel squares. (This simple math also avoids problems with seams when drawing abutting bitmap images.) But 3840x2400 is greater than the number of physical pixels in the display hardware. So, that backbuffer is scaled down when actually drawn on the screen to the physical 2880x1800 pixels. This loses some of the higher detail from the backbuffer, but the results are still finer-detailed than either a physical 1920x1200 screen or scaling up a 1920x1200 rendering to the physical 2880x1800 screen.
So, for this configuration:
Screen size in points: 1920x1200
Backbuffer in in-memory pixels: 3840x2400
Physical pixels in display hardware: 2880x1800
Other configurations are, of course, possible:
Screen size in points: 2880x1800
Backbuffer in pixels: 2880x1800
Physical pixels: 2880x1800
Everything will be teeny-tiny but you'll be able to fit a lot of stuff (e.g. many lines of text) on the screen.
Screen size in points: 1280x800
Backbuffer in pixels: 2560x1600
Physical pixels: 2880x1800
This will actually make everything (text, buttons, etc.) appear larger since there are fewer points mapped to the same physical pixels. Each point will be physically larger. Note, though, that each point still maps to a 2x2-pixel square in the backbuffer. As before, the backbuffer is scaled by the hardware to the physical display. This time it's scaled up slightly rather than down. (This scaling is the same thing as happens on a non-Retina LCD display when you select a mode with fewer pixels than the physical display. Obviously, an LCD can't change the number of physical pixels it has, so the different resolution is accomplished by scaling a backbuffer.)
Etc.
I am learning Windows 8 metro style app development, I want to set a background photo in my app, it will fit the full screen, should I provide different sizes of this image so that it can fit all devices? If i should, which detailed sizes should I provide?
Should I provide different sizes so that it can file all devices?
Yes
which detailed sizes:
You should provide images that scale for different resolutions as well as sizes. Common sizes include (these come from the Windows 8 simulator - you can test you app with these sizes):
1024 x 768
1366 x 768
1920 x 1080
There are also recommendations for providing images at different resolutions (100, 140, 180 dpi).
Please make sure you check out:
Guidelines for scaling to screens
Guidlines for scaling to pixel density
I uploaded a test video on YouTube with a 2.39:1 aspect ratio and YouTube converted it into the following qualities: 240p, 360p 480p, 720p, 1080p.
I downloaded the 1080p video to check its dimensions and they were 1920 x 664, or an aspect ratio of 2.89:1.
Does that mean that "1080p videos" don't need to have a 16:9 aspect ratio?
Let's say I have two videos, both 1920x1080.
Does that mean that both videos have same aspect ratio of 16:9 ?
Does that mean videos qualified as 1080p need to have:
dimensions 1920x1080
aspect ratio 16:9
Wikipedia says "1080p is a set of HDTV high-definition video modes that are characterized by 1080 horizontal lines of vertical resolution and progressive scan. The term assumes a widescreen aspect ratio of 16:9, thus implying a resolution of 1920 × 1080 (2.1 megapixels)," although no credible source is cited.
YouTube/Google define their interpretation of 1080p in YouTube Player API Reference for Embeds: Playback quality:
Quality level hd1080: Player height is 1080px, and player dimensions
are 1920px by 1080px (for 16:9 aspect ratio) or 1440px by 1080px (for
4:3 aspect ratio).
I've never heard of a 2.89 aspect ratio. 16/9 = 1.7̅ 1920 x 664 is really strange. Maybe it's a bug in YouTube's converter. But I guess you could gain more control by uploading video which you've already converted to a standard aspect ratio yourself.