I am developing a fixed size HTML5 DOM-based game. It got animations and graphics naturally. It is fixed at 1000px x 620px but I cant make the game scale down proportionally for different sizes of devices. I fits nicely on iPad but I only see part of the game on iPhone for example.
I thought it was easy thing to do to just scale the whole thing down (inc. graphics) but I can't find a solution for that.
What are my options, right now I am thinking of 3 totally diffenct CSS with media queries one for iPad, iPad mini and iPhone. but its seem to be a lot of extra work to do.
Thanks for any help!
You could try iframing your page and using standard transforms to scale it to the size you need. It is probably better to make your game non height/width dependent, but this may work to fix the issue quickly:
iframe {
-ms-zoom: 0.25;
-transform: scale(0.25);
-moz-transform: scale(0.25);
-moz-transform-origin: 0 0;
-o-transform: scale(0.25);
-o-transform-origin: 0 0;
-webkit-transform: scale(0.25);
-webkit-transform-origin: 0 0;
}
Related
I wrote a JQM web app for Android and iPhone that runs in a custom native container that comes with a bunch of vendor libraries, including a custom version of iScroll. Recently, we upgraded the libraries from the vendor, including iScroll. Now, iPhone users are seeing visual distortion under certain conditions (screenshot: http://i.stack.imgur.com/mCUyB.png). The distortion correct themselves after scrolling.
Symptoms:
horizontal lines are being drawn on the right of the screen
Elements in the iscroll div are stretching past the right hand side. (Notice the divs has round edges on the left side, but not on the right. This also corrects itself after scrolling.
When both of these conditions are met, it triggers the distortion:
After downloading a larger dataset, causing more DOM elements to be attached to the iscroller
When the user navigates backwards. Essentially, when JQM page and its attached elements go from hidden to visible.
CSS code of the div iscroll:
element.style {
-webkit-transition: -webkit-transform 0ms;
transition: -webkit-transform 0ms;
-webkit-transform-origin: 0px 0px;
-webkit-transform: translate3d(0px, -131px, 0px) scale(1);
}
A few more observations:
I suspect the iscroll is because the previous iscroll version did not use -webkit-transform.
on iPhone, -webkit-transform: translate3d is hardware accelerated.
the distortion is only on iPhone, not on Android.
Not sure what other information I should provide. I could provide the code for the iscroll, but it's 800 lines of code.
This is my first post here. Be Gentle.
I was having some issues with iScroll 5 where images and even text would get distorted when scrolling to some items (works fine on browsers but fails on iPhones/iPads).
I have 4 tabs with one scroll each. The first one works fine (maybe because it has less items?), but the others fail when scrolling to the last item or so.
After some tests, I noticed that removing the CSS transition on the container (with the #id that I'm using to call the iScroll), solved the problem. I'm still keeping the transitions though. I just had to move it to a different container down on the DOM tree. (on my case it was just a fade in effect when the scroll finishes loading).
It's a really strange bug... Hope it helps you solve your problem too.
getting really confused here now after googling for the last 40 mins. I need a definite answer.
Im making a webapp for ipod touch, iphone(all gens) it i will be run in full screen mode as a native app eventually.
however what i want to know is. what width: and height: do i set my wrapper to in the css.... i need the dimentions, i get 960wide, 320wide 640wide i get all confused, i just need a definite answer of how many pixels wide it should be and high in portrait mode.
thanks
The Dimensions should be
Width: 320 x Height: 480
source: http://en.wikipedia.org/wiki/IPhone
Could you not set it as a percentage and have it always fill the screen no matter the device used .. iPad, iPhone# etc.
For example:
.container {
width: 94%;
margin: 0 3%; /* Give it some space from the sides. */
min-height: 100%;
}
Something along those lines?
You would need to set your wrapper width to 320px for portrait mode, although the user will have the option to view the web app in landscape mode so if you can get away with using percentages (i.e. wrapper {width:100%}) you'll be better off.
Working with phoneGap implementing drawing with Canvas. The catch we've run into is that canvas expects specific pixel dimensions. This is fine except that the iPhone 4's Retina display, from a CSS/Webkit POV is still 320px wide, even though technically there are 640 actual screen pixels.
Is there anyway to accommodate the retina display using Canvas on Webkit while preserving compatibility with non-retina displays?
I sat with the same problem last week and discovered how to solve it -
var canvas = document.querySelector('canvas');
var ctx = canvas.getContext('2d');
if (window.devicePixelRatio > 1) {
var canvasWidth = canvas.width;
var canvasHeight = canvas.height;
canvas.width = canvasWidth * window.devicePixelRatio;
canvas.height = canvasHeight * window.devicePixelRatio;
canvas.style.width = canvasWidth + "px";
canvas.style.height = canvasHeight + "px";
ctx.scale(window.devicePixelRatio, window.devicePixelRatio);
}
Full code on gist, demo on jsfiddle
There is a drop-in polyfill that will take care of most basic drawing operations for you, and remove the ambiguity between browsers that handle this automatically for you (safari) and others that don't.
https://github.com/jondavidjohn/hidpi-canvas-polyfill
You simply include it before your drawing code and it should give you decent retina support automatically.
I couldn't find anywhere else on the internet suggesting this so I figured it out. If you have a full screen canvas and you want it to be the actual amount of pixels that the device has, just remove this line from your HTML:
<meta name='viewport' content='width=device-width' />
Don't set the viewport at all. Then you just do:
canvas.width = innerWidth
canvas.height = innerHeight
canvas.style.width = innerWidth+'px'
canvas.style.height = innerHeight+'px'
That will use the full screen resolution of the device.
A pixel will always be a pixel.
You don't need to scale.
And getImageData() will give the same values that you see.
WebCode (http://www.webcodeapp.com) is a vector drawing app that generates JavaScript HTML5 Canvas code for you. The code is Retina-compatible, you can check out how they do it.
There is a very good polyfill by TJ Holowaychuk:
https://www.npmjs.com/package/autoscale-canvas
EDIT: Just noticed I posted the wrong link for the demo!
Retina (or other hdpi display) canvas resolution is definitely possible. There is a working example here:
http://spencer-evans.com/share/github/canvas-resizer/
I've also bumped into this a few times. The accepted answer code is essentially correct, but you could also use a library solution. I whipped one up to handle intelligent canvas re-sizing to make the element more responsive and higher resolution (as shown in the demo).
https://github.com/swevans/canvas-resizer
I am using the Jquery/Jqtouch libraries for an iphone compatible site. I am now stuck with a problem just in iPhone 4 (not in 2g, 3g or 3gs) where the text becomes blurry on one specific scenario. Below is how it happens
The site has one common div container.
<div id="container"></div>
The container is filled with content dynamically based on the user action. Below is the function that does that.
function loadPage(url, section, callback) {
$('#container').empty();
$('#container').load(url + ' ' + section, loadComplete(section));
}
One sample call to the above function
loadPage("Data.htm", "#Friends", null);
Basicaly eveything works fine except on one scenario where the amount the data on the container is huge (ie the #container height increases to 1500px+ not predictable). Now if i replace it with smaller data for different tabs on the same container then the text becomes blurry. Attached is the image
http://i.stack.imgur.com/XE9q4.png
Did anyone come across this scenario. Thanks in advance.
Try closing all your running apps besides safari. It sounds crazy but we have the same problem on the ipad and it just seems to be running out of memory at some point. Closing all the apps stops it. Other thing that seems to make a difference is -webkit-overflow-scrolling:touch, if it doesnt have this property then it doesnt seem to have the problem described.
i was able to fix this by applying the same settings to reduce flicker on the element in webkit browsers:
-webkit-perspective: 1000;
-webkit-transform-style: preserve-3d;
-webkit-backface-visibility: hidden;
Graphics elements must be "aligned" with the pixels on the screen; coordinates must always expressed as integral values and not floating values. If not, the subpixel rendering engine of the GPU would make it blurry, which is not a problem with animation but definitely one with static images.
In the native SDK, we have to make sure everything is aligned (such as using CGRectMakeIntegral()).
Since you're using a web framework, it's more difficult to tell how to exactly how fix the problem, but I would try to adjust the sizes of your to a precise size and not let the framework figure it out.
What content do you load? Images? Text? There's an internal limit on image sizes for the iPhone (about 4 Megapixels or so). It looks like the phone is trying to reduce the memory load of your website and reduces the resolution to non-retina values.
I can't say more without you posting code.
This is a shot in the dark, but have you aset your sizes using pt values for your block elements, and em for your text?
The iphone4 resizes your content to fit its higher-res Retina display (compared to the older iphone), and with that scaling i have sometimes noticed blur when using pixel values for block height, width, font size, etc.
Very hard to diagnose without seeing the actual code, but could be the issue.
In my case it was CSS
-webkit-transform: translateZ(0);
applied to one of the elements in body. So as Ariejan said, it's removing transition property that fixes it.
body{ text-rendering: optimizeLegibility}
could solve this issue, worth a shot if you haven't included it already
Sometimes, Text blurry may be cause of the iScroll Plugin. Did you use this?
Try to comment
trnOpen = 'translate' + (has3d ? '3d(' : '('),
trnClose = has3d ? ',0)' : ')',
According to Apple, the iPhone 4 has a new and better screen resolution:
3.5-inch (diagonal) widescreen Multi-Touch display
960-by-640-pixel resolution at 326 ppi
This little detail affects our apps in a heavy way. Most of the demo apps on the net have one thing in common: They position views in the believe that the screen has a fixed size of 320 x 480 pixels. So what most (if not all) developers do is: they designed everything in such a way, that a touchable area is (for example) 50 x 50 pixels big. Just enough to tap it. Things have been positioned relative to the upper left, to reach a specific position on screen - let's say the center, or somewhere at the bottom.
When we develop high-resolution apps, they probably won't work on older devices. And if they do, they would suffer a lot from 4-times the size of any image, having to scale them down in memory.
According to Supporting High-Resolution Screens In Views, from the Apple docs:
On devices with high-resolution screens, the imageNamed:,
imageWithContentsOfFile:, and
initWithContentsOfFile: methods
automatically looks for a version of
the requested image with the #2x
modifier in its name. It if finds one,
it loads that image instead. If you do
not provide a high-resolution version
of a given image, the image object
still loads a standard-resolution
image (if one exists) and scales it
during drawing.
When it loads an image, a UIImage object automatically sets the size and
scale properties to appropriate values
based on the suffix of the image file.
For standard resolution images, it
sets the scale property to 1.0 and
sets the size of the image to the
image’s pixel dimensions. For images
with the #2x suffix in the filename,
it sets the scale property to 2.0 and
halves the width and height values to
compensate for the scale factor. These
halved values correlate correctly to
the point-based dimensions you need to
use in the logical coordinate space to
render the image.
This is purely speculation, but if the resolution really is 960 x 640 - that's exactly twice as high a resolution as the current version. It would be trivially simple for the iPhone to check the apps build target and detect a legacy version of the app and simply scale it by 2. You'd never notice the difference.
Engadget's reporting of the keynote included the following transcript from Steve Jobs
...It makes it so your apps run
automatically on this, but it renders
your text and controls in the higher
resolution. Your apps look even
better, but if you do a little bit of
work, then they will look stunning. So
we suggest that you do that
So I infer from that, if you use existing APIs your app will get scaled up. If you take advantage of new iOS4 APIs, you can get all groovy with the new pixels.
It sounds like the display will be ok but I'm concerned about the logic in my game. Will touchesBegan positions return points in the new resolution? The screen bounds will be different, these types of things could potentially be problems for me.
Scaling to a double resolution for display purpose is straight forward, but will this scalling apply to all api's that input/output a screen coordinate? If not things are going to break aren't they?
Fair enough if it's been handled extensively throughout the framework.. I would imagine there are a lot of potential api's this effects.
For people who are coming to this thread looking for a solution to a mobile web interface, check out this post on the Webkit blog: http://webkit.org/blog/55/high-dpi-web-sites/
It seems that Webkit has solved this problem four years ago.
Yes it is true.
According to WWDC it appears that apple has build it some form of automatic conversion so that the resolution for applications will not be completely off. Think up-convert for dvd to HDTV's.
My guess would be that apple knows what most of the standards developers have been using and will already be using these for an immediate conversion. Of course if you are programming an application to take advantage of the new resolution it will look much nicer than whatever the result of apples auto-conversion is.
All of your labels and system buttons will be at 326dpi but your images will still be pixel doubled until you add the hi-res resources. I am currently updating my apps. If you build and run on the iPhone 4 sim then it is presented at 50%, go to Window > Scale > 100% to see the real difference! Labels are smooth, my images look shocking!