How to support multiple screen resolutions with Vue? I couldn't find anything about multiple resolutions supporting on nativescript-vue.org.
The default measurement is DIP (Density Independent Pixels) that makes your app mostly look good on different resolution.
But if you still prefer to write CSS specific to a platform / device / screen resolution / orientation, try nativescript-platform-css.
If you want to completely change the layout of your page then you might have to write different components and load them based on your screen resolution.
Related
I'm creating an app for Android and I should load images from a CDN and I want to support all the possible screen sizes. How should be done?
Should be many different versions of the same image stored in the CDN in different folders? Or one only resolution can cover all the screen sizes if it has high resolution?
Also How I know the exact numberXnumber? how I can know that? I should try manually or there are guidelines?
For example if that helps I have an ImageView 100dpX100dp how I know how much should be the pixels?
Thanks
You should probably set up essentially the basic ranges that android uses, mdpi, hdpi, hdpi-x, hdpi-xx. So you would have low and medium resolution screens request cdn.com/mdpi/image.png, high resolution request cdn.com/hdpi/image.png and so on... You define the resolutions within each grouping, for example on hdpi-xx Your images may be 1920x1080, but on hdpi it is only 1280x720. Those are just examples pulled out of the air, but you can adjust to suit your needs.
You can even use the base android resource system to pull the correct url for each screensize.
i.e.
In the folder values-mdpi you put a string resource that will have the url with mdpi, and hdpi with the base url for hdpi, you get the idea.
For further information you the documentation here provides very clear examples and more detail.
When I make a new Universal App in Visual Studio 2013 I get a number of graphics files for the logos, splash screens, etc. in the Assets folder, for example Square71x71Logo.scale-240.png. The Package.appxmanifest then maps these files to the various required things. For example Square71x71Logo.scale-240.png is mapped in Package.appxmanifest to Square 71x71 Logo.
The actual file is 170 pixels wide, 170 pixels high, Photoshop reads it as having 72 pixels per inch, and it has an 8 bit colour depth.
What does the .scale-240 part of the file name signify?
I'm replacing the file and I am not sure how to scale-240-ify the new image.
The scale-240 part of the file name is a resource qualifier that indicates that the file is used for 240% DPI systems.
Resource qualifiers allow the app to provide different versions of the same resource for different scenarios and refer them all internally by the base name:
Scaling for different DPI systems: .scale-100, .scale-140, .scale-180, .scale-240
Language (if the image has text in it): .lang-de-DE, .lang-en-us
Contrast (to simplify for high contrast modes): .contrast-high, .contrast-standard
Layout direction (if the image should be different in LTR vs RTL language settings): .layoutdir-RTL, .layoutdir-LTR
DirectX feature level: .DXFL-DX9, .DXFL-DX11
The app can reference the image by its base name (e.g. logo.png) and the version which best matches the current scale, contrast level, language, etc. will be automatically used.
The default phone template provides scale-240 images since high-DPI phones are fairly common and it is generally better to scale down from a larger image than to scale up a small image. Best would be for you to provide multiple resolutions when you replace the stock ones with your own, especially if your images are complicated and don't scale well by default.
See How to name resources using qualifiers (XAML)
Universal apps need to be able to run on very different screens. You cannot predict up front what kind of device the user might have. Big difference if he has a cheap contract phone, an expensive slate or a desktop machine. WinRT helps by automatically scaling your app to match the screen resolution.
Supported scaling percentages for a desktop/slate app are 80, 100, 140 or 180%. For a phone it is 100, 140 or 240%.
Text can auto-scale easily but images do not. They get blurry when they get rescaled, a single pixel in the image no longer coincides with a single screen pixel. Pretty noticeable when the image contains fine line art or text. Scaling down necessarily loses pixels, details may disappear.
So the Visual Assets tab of the manifest editor allows you to select multiple images, each suitable for a specific scaling percentage. You found the -240 version in your phone project's Assets directory, the 240% scaling version that were auto-generated when you created the project. The desktop version has -100 assets by default, 100% scaling.
You may want to add your own. You don't have to.
.scale-xxx appears to refer to pre-scaled image resources.
If you are using a an image logo.png with size 100x100px then logo.scale-240.png should be an image of size 240x240px, i.e. scaled by a factor of 240 percent. The idea behind this concept is apparently to avoid potentially expensive and inaccurate rescaling by the displaying device, by supplying several prescaled images at defined scales.
In your case: 170px / 2.40 = ~71px
See also the corresponding MSDN article. (The linked article is in German, I will leave it to the interested reader to find the matching English one ;-)
I'm building a new app with this great tool and i have a question to solve.
What is the best way to handle imnage size for multiple scren and multiple devices.
Apple = retina and non-retina
Android = ldpi, mdpi, hdpi, xhdpi, xxhdpi and tablets (all this with multiple screen resolution)
BlackBerry10 = one resolution (but not equal to the others)
WindowsPhone8 = one resolution (but not equal to the others)
For this case, what is the best way ?
Use SVG images (Optimizacion, perfomance, size of app) ??
Dedicate CSS tags for device pixel ratio (CSS Image Replacement) (the designer can kill me :smile: lol ) see the list http://bjango.com/articles/min-device-pixel-ratio/
CSS Sprite sheet
Another way
Before the decision, think in what is the best to apply in all devices.
Thanks in advance
There really isn't a single way to do this since each implementation of an image will require a different approach depending on its purpose. SVGs are great but not everything works as an SVG.
Media queries will be your ally.
See this: supporting multiple resolution and density of images in phonegap
and this for an alternate approach: Angular.js data-bind background images using media queries
There are also some nice polyfills for the html5 picture element which you might find useful.
See: https://github.com/scottjehl/picturefill
...and its angularjs directive implementation https://github.com/tinacious/angular-picturefill
I'm planing to create a blog and I'm thinking about how to serve images in the best possible quality without affecting loading times for mobile devices too much.
My content column is aprox. 768 display points wide and I'm posting screenshots using a retina Macbook so the images will be at least 1500px wide. Other Retina/HIDPI users should see the version best for them.
Is there a recommended best practice for this case? I'm talking only about content images (<img />); no CSS backgrounds. A true WordPress solution that serves images based on the uploaded hires images would be great.
I have used adaptive images in the past but it does not distinguish between HIDPI and normal clients. Other solutions serve for retina but not for different screen sizes.
No, there is no good method for doing this. This isn't a fault of WordPress, but of the state of the web in general. HiDPI on the web is currently a big hack, basically, and the web has not yet adapted to it properly.
Basically, there's no good way to specify multiple resolution images in the HTML in a way that the browser can then use to determine the proper image to show. CSS works, but only if you're using images as backgrounds. If you're dealing with IMGs, then you have to rely on Javascript to do the job, and that has various downsides depending on your methodology.
In the future, when browsers have started to adopt methods for specifying multiple resolution images, then this won't be as much of a problem.
Edit: This deserves a bit more explanation.
The basic problem with using JS to do this is that it relies on a technique of image-replacement. The JS code, through whatever logic it has, finds the IMGs on the page, then replaces them with higher resolution versions from some other file. No matter what method is used to do this, it has two major downsides:
First, the initial image is loaded in low resolution, then loaded again in high resolution when the image is replaced. This means extra bandwidth usage, and considering most HiDPI devices are currently mobile ones, this doesn't make much sense to waste that sort of bandwidth on those devices.
Second, the image is generally first displayed in low resolution and then replaced with the high resolution image. This means that there's a second or two of showing a fuzzy image on HiDPI screens, before it "pops" into focus as the replacement occurs. This is a really crappy effect to have.
Other methods exist by which you can simply serve the proper image in the first place, but they have downsides as well.
Server-side browser detection by User-Agent is a pretty crappy way to do things in the first place, and best avoided simply because there's so many different agents out there in the wild that maintaining a list of them is virtually impossible. However, if you want to go through the pain of it, this method can work.
Alternatively, it's possible to have Javascript in the browser detect the device-pixel-ratio of the browser and set that in a Cookie to return to the server. The server can then use this cookie to serve the proper resolution image. This works, but is unreliable because many mobile user agents fail to properly set and return the cookie, and even on those that do, the high-resolution images would only be shown on the second visit to the page. First impressions are low-res, which isn't good in general.
Like you can see: It's just hacks all the way down. Until the browser is capable of being told for a specific IMG that multiple versions exist, and their parameters, and then being allowed to choose for itself, then these are the only ways to do it. But, if things like the proposed HTML5 "srcset" or the PICTURE tag are implemented, then we'll have better choices.
After thinking a while about this, I have to offer two ways to approach (parts of) this problem (partly). Still: Read the answer from #Otto carefully. It has a lot of in depth details for a reason.
Javascript detection
I wrote an answer about »How to add default images« for attachments. You can alter the filter callback to always add a simple png/gif (that has just the background color) instead of the normal image or thumbnail. This would help you serving an extremely small image (maybe below 1kB - smushIt for the rescue) that the user agent/browser would cache at the first load and then simply insert for each other call to an image.
Then, simply the display pixel density with…
var dpr = 1;
if ( window.devicePixelRatio !== undefined )
dpr = window.devicePixelRatio;
if ( dpr > 1 ) {
// High pixel density pixel displays
}
…exchange the images when the DOM has fully loaded.
CSS routing
Adding stylesheets for different pixel density displays isn't that hard:
// For default/low density pixel displays only:
wp_enqueue_style(
'low_density_styles'
,trailingslashit( get_stylesheet_directory_uri() ).'low_density.css'
,array()
,filemtime( locate_template( 'low_density.css' ) )
,'screen'
);
// For high density pixel displays only:
$media = 'only screen and (min--moz-device-pixel-ratio: 2), ';
$media .= 'only screen and (-o-min-device-pixel-ratio: 2/1), ';
$media .= 'only screen and (-webkit-min-device-pixel-ratio: 2), ';
$media .= 'only screen and (min-device-pixel-ratio: 2)';
wp_enqueue_style(
'high_density_styles'
,trailingslashit( get_stylesheet_directory_uri() ).'high_density.css'
,array()
,filemtime( locate_template( 'high_density.css' ) )
,$media
);
Now you can simply switch between high/low density images - for your default images (header, logo, etc.). This doesn't work for post type attachments (again: refer to #Otto answer).
I am using OGRE to make a re-rendering of the film, which has a wide aspect ratio (around 1.85). The OGRE dialog seems to be showing the standard full screen resolution by default (800/600, 1024/768, etc.), but those obviously have aspect ratios of 1.333 or around that. But as long as I am not running full screen mode, why should I be restricted to these screen sizes only?
I can definitely change the viewport size, but that would make it difficult for me to generate the video later.
Any idea?
There are no any restrictions for using non standard (4:3) aspect ratio screen resolution in Ogre. Default OGRE configuration window just show list of defaults resolution.
But if you need other screen side you should create it from the code directly depending on the dimensions of your input video.