With the new screen resolution and aspect ratio of iPhone 5 it seems there are two approaches to take advantage of the new screen real estate when handling images that are full screen (or mostly full screen) images:
Include two images bg#2x.png and bg-h568#2x.png and check the device's main screen bounds to figure out which to load.
Only include the one file but make it the full iPhone 5 resolution
(There are other methods also: stretching, tiling, and / or drawing with Quartz.)
Both of these options have drawbacks:
Including two files is going to increase your app's bundle size
Loading a iPhone 5 retina image on a 4 will clip the image data when displayed on screen, but will still consume the same amount of memory resources
I am particularly interested in understanding the details of the second drawback better.
I am thinking it would save the app bundle (and my designer) if I could use this consolidating images idea further...
Let's say I have an image that take up 320pt x 480pt in portrait and 480pt x 320pt in landscape (width x height).
(EDIT: Initially I hadn't considered a couple of other important tidbits. For sake of completeness, I'm including those thoughts here)
If we create a single image file at a 480pt x 480pt resolution instead of landscape and portrait files, it would prevent the app bundle from having two files that which each contain 320pt x 320pt area of duplicate image data. However, this large square image would include four 80pt x 80pt quadrants in the corners that won't be seen. All things equal, we should still have 20% less image data in the app bundle.
Having re-read Bill's "iBooks Author Experiment", the memory requirements are very easy to figure out:
Landscape or Portrait: 640 * 960 * 4 = 2,457,600
Large Square: 960 * 960 * 4 = 3,686,400
The memory required to load the large square is 50% more then loading the image sized correctly for the screen. Clearly the savings in the app bundle don't measure up to this hit on resources!
But, what about extending this to a giant square that would encompass iPhone 5 and iPhone 4 - 568pt x 568pt? Instead of four files (iP4 landscape, iP4 portrait, iP5 landscape, iP5 portrait), there would be only one file in the app bundle (giant square). The savings could be about 60%.
What about the resources hit?
iPhone 5 Landscape or Portrait: 1136 * 640 * 4 = 2,908,160
Giant Square: 1136 * 1136 * 4 = 5,161,984
That's 110% more memory for iPhone 4, and 77.5% more memory for iPhone 5.
My original question was roughly two parts: 1. Do I understand this correctly and 2. is this tradeoff a wise one to make.
I hope my edits (spurred by Bill's answer) show that I do understand this stuff now. And, if the new found knowledge is correct, then #2 pretty much answers itself. :-)
Generally you get it.
Assuming that you have the big square image and it's some kind of tiled pattern (linen etc) then you could use ImageIO to load the cropped image at the size you need which would use some extra memory decompressing the image but once done it would consume only what is needed to fill the background.
I would suggest against scaling the image.
On the flip side though, shipping an app with 3 images (foo, foo#2x and foo-h568#2x) instead of 1 makes way more sense. The only way I'd say you should go with one image is if you are close to the 3G/LTE download size of (I think) 50MB.
Related
Just a straight forward question. I´m trying to make the best possible choice here and there is too much information for a "semi-beginner" like me.
Well, at this point, I´m trying with screen size values for my layout (activity_main.xml (normal, large, small)) and with different densities (xhdpi, xxhdpi, mhdpi) and, if a can say so myself, it is a mess. Do I have to create every possible option to support all screen sizes and densities? Or am I doing something really wrong here? what is the best approach for this?
My layouts are now activity_main(normal_land_xxhdpi) and I have serious doubts about it.
I´m using last version of android studio of course. My app is a single activity with buttons, textview and others. Does not have any fragments or intents whatsoever, and for that reason I think this has to be an easy task, but not for me.
Hope you guys can help. I don't think i need to put any code here, but if needed, i can add it.
If you want to make a responsive UI for every device you need to learn about some things first:
-Difference between PX, DP:
https://developer.android.com/training/multiscreen/screendensities
Here you can understand that dp is a standard measure which android uses to calculate how much pixels, lets say a line, should have to keep the proportions between different screensizes with different densities.
-Resolution, Density and Ratio:
The resolution is how much pixels a screen has over height and width. This pixels can be smaller or bigger, so for instance, if you have a screen A with 10x10 px whose pixels are two times smaller than other screen B with 10 x 10 pixels too, A is two times smaller than B even when both have 10 x 10 px.
For that reason exists the meaning Density, which is how much pixels your screen has for every inch, so you can measure the quality of a screen where most pixels per inch (ppi) is better.
Ratio tells you how much pixels are for height as well as width, for example the ratio of a screen of 1000 x 2000 px is 1:2, a full hd screen of 1920 x 1080 is 16:9 (16 pixels height for every 9 pixels width). A 1:1 ratio is a square screen.
-Standard device's resolutions
You can find the most common measurements on...
https://material.io/resources/devices/
When making a UI, you use the DP measurements. You will realize that even when resolution between screens are different, the DP is the same cause they have different densities.
Now, the right way is going with constraint layout using dp measures to put your views on screen, with correct constraints the content will adapt to other screen sizes
Anyway, you will need to make additional XML for some cases:
-Different orientation
-Different ratio
-Different DP resolution (not px)
For every activity, you need to provide a portrait and landscape design. If other device has different ratio, maybe you will need to adjust the height or width due to the proportions of the screens aren't the same. Finally, even if the ratio is the same, the DP resolution could be different, maybe you designed an activity for a 640x360dp and other device has 853x480dp, which means you will have more vertical space.
You can read more here:
https://developer.android.com/training/multiscreen/screensizes
And learn how to use constraintLayout correctly:
https://developer.android.com/training/constraint-layout?hl=es-419
Note:
Maybe it seems to be so much work for every activity, but you make the first design and then you just need to copy the design to other xml with some qualifiers and change the dp values to adjust the views as you wants (without making from scratch) which is really faster.
I have a contentView which cover the whole galaxy s4 screen. When I debug in onSizeAllocated it return 680 * 335 around that amount. My device screen should be more than that.
I wanted to know the width of the screen so I can evenly distributed a square image in a grid.
In summary:
These sizes are not pixels. Instead, they are device-independent units recognised independently by each platform.
Check out the documentation.
What onSizeAllocated is returning is a internal representation of size managed by Xamarin.Forms. Its not the current pixels of your device.
To get the current screen size, you have a lot of options, but i will put it here some pointers to get there.
1 - On SO, more
2 - With Xlabs
3 - Recent plugin
I'm totally new when it comes to xcode, but there occured a problem:
I'm designing an iPad-App(Retina Display) in html/css with the standard retina resolution of 2048x1536px...the problem is, that when I open the app on the pad, the page turns out to be way too huge. If I'm reading out the UiWebView-Resolution I get 1024x768...am I able to change this to get the real iPad dimension?
thx for your help!
Best regards,
daft
Dimension values on iOS are described in points. Each point can have different number of pixels - depends on screen's pixel density. UIWebView interprets html document size value as point - so 1 html pixel means 1 point.
I suggest you two options to cope with that:
1. Design you're web app to resolution 1024x768 and insert images which are scaled to 50% size to have more pixel density.
2. Leave page in 2048x1536 resolution and use UIWebView api to scale content.
I understand the use of thumbnail in network applications but assuming all the image are in the application itself (photo application), in this case do we still need thumbnail images for performance reasons or is it just fine for the device to resize the actual image on run time?
Since the question is too opinion based I am going to ask more quantitively.
The images are 500x500, about 200-300kb size jpg.
There will be about 200 images.
It is targeted for iphone4 and higher, so that would be the minimum hardware specs users will have.
The maximum memory used should not pass 20% of the devices capacity.
Will the application in this case need separate thumbnail images?
It depends on your application. Just test performance and memory usage on device.
If you show a lot of images and/or they change very quickly (like when you are scrolling UITableView with a lot of images) you will probably have to use thumbnails.
UPDATE:
When image is shown it takes width * height * 3 (width * height * 4 for images with ALPHA channel) bytes of memory. 10 photos 2592 x 1936 stored in memory will require 200Mb of RAM. It is too much. You definitely have to use thumbnails.
Your question is a bit lacking on detail but I assume you're asking if, for say a photo album app, can you just throw around full size UIImages and let a UIImageView resize them to fit on the screen, or do you need to resize?
You absolutely need to resize.
An image taken by an iPhone camera will be several megabytes in compressed file size, more in actual bytes used to represent pixels. The dimensions of the image will be far greater than the screen dimensions of the device. The memory use is very high, particularly if you're thinking of showing multiple "thumbnails". It's not so much a CPU issue (once the image has been rendered it doesn't need re-rendering) but a memory one, and you're severely memory constrained on a mobile device.
Each doubling in size of an image (e.g. from a 100x100 to a 200x200) represents a four-fold increase in the memory needed to hold it.
After reading posts on this site and others, I am uncertain what pixel width I should make for a background cover image. For retina devices it is recommended to create a background image x2 the size if for a non-retina device.
I want to create a background image that will cover the entire screen but this would make a retina device image 2560 x 1760 and non-retina 1920 x 1200 if accommodating large monitors.
Is this too big?
I can't keep the jpeg image file size down to 276KB and that is with the most compression I can apply without destroying the image quality
Well your question is very interesting. To address your comment about what pixel width you should design your background image for. The size of a screen for a laptop, or desktop can vary. So you'll never exactly be able to make a single "universal" image for all backgrounds. Generally diagonal display in inches decides the amount of pixels. My screen is quite large, roughly the biggest size commercially purchased by public. Which is of course 1600 x 900 pixel, 17.3" diagonal display. I wouldn't recommend designing images for any display larger because those displays are custom and more for people who do things like graphic design themselves. Visit http://nodejs.org/logos/ If you scroll down to the computer display, you can see a list of pixel ratios that nodejs designs its logos for. These are very mainstream and popular display sizes. I would recommend you do the same and use those. Hope this answer helped.
Edit: nodejs builds for quality up to 2560 x 1440. If the size of the files doesn't matter. You should easily be able to build for sizes this large. Hope this helped.