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)' : ')',
Related
I'm trying to optimize our News pages for iPhone. One problem I've noticed is that I'm able to tap and move the page horizontally (i.e. wiggle).
My question is, how I can prevent this horizontal movement from happening?
All of our News pages have this problem. Here are a couple examples:
With picture
Without picture
Something is definitely set greater than your device width. Add the following to your css to find the culprit.
* {
border-style:solid;
}
You can then narrow down your search by setting border-color:red; to individual classes/tags/ids.
Add "overflow-x: hidden" on the body.
You can try setting user-scalable=0; and see if that has any effect.
This just happened to me too and it was the result of an extra closing div tag. Once I removed the extra </div>, the horizontal "wiggle" didn't happen any more.
I too, had the iPhone "wiggles" on a web page. It ended up being caused by an image that was wider than the column width it sat in (it was the last column in the row using Twitter Bootstrap). You might be thinking "obvious", but it's hard to spot when the image background matches the page background.
Just make the image responsive, or smaller than the column width - that solved it for me.
Taking the idea from other websites, most of big sites have a mobile site. look at those (the only one i know is facebook m.facebook.com) you can maybe see how the css is done. possible way of doing this is %. I would suggest to take out the sidebar for the mobile version. big pictures should be taken out or be resized so the browser doesn't have scroll bar side to side.
I need to show a PDF in my view and zoom and scroll it. I tried using the example from Apple. It works, but when I zoom in/out the image appears to be very pixelated and the result is very bad... can you help me avoiding the bad quality when I zoom ( when I finish to zoom, the pdf is shown right...)
Thanks in advance.
The zoom is implemented this way to reduce resource usage while zooming, because rendering a PDF page can be very resource intensive. During zooming a bitmap version of the page is used for display and when the zoom ends, the PDF page is rendered again. You could implement continuous page rendering during zooming but I'm afraid the result would be unusable.
Note that this does not really answer your question, but I don't think that the pixelation is a problem. The few milliseconds where the PDF is pixelated are not a big deal and will barely be noticed. The Apple apps do it like this too, I think - or at least they are not constantly updating the image/PDF.
Currently I'm trying to edit a login screen for a web based application. As of now, I have the login prompt (user & password) at a particular place on page so that it corresponds with the background image. Right now this image is set to 1024x768.
What I was wondering, is there a way to have the background automatically scale depending on users own resolution while have the login appear at the correct location? I'm not sure if this is possible but thought someone might have some advice.
I've made a jsFiddle solution that can come in handy:
Click here to see background-resizing at work
It works with jQuery, and I've commented most code so you can understand how it works. You compare the aspect ratio of the image and the browserwindow, look at the difference and then resize the width or height, based on how the aspect ratio's are comparing. The css is also worth a look.
I tested it in Firefox and IE(7/8), but jsFiddle resizing is a bit buggy in IE.
Good luck!
Update:
I've made an updated jsFiddle here.
In this scenario, the message box (in your case the loginbox) is positioned absolute with percentual offset to the top and right. I also gave it percentual width/height, although that might not be neccesary/wanted. But you can tweak this to see how the box behaves with different window sizes.
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!
I'm displaying a PDF file using UIWebView, and I want to do 2 things:
I want to make the page fit the phone screen without the user has to double tap to do that
I want to remove the margin with gray shadow around the displayed PDF
Thanks for helping
I don't think this will help much, but I think your best option is to render the PDF to an image (of decent DPI) and show the image instead. I do this for an app, but we do that server side using ImageMagick - don't know how you might do that in obj-c. Also note that a mostly-text PDF will be much larger (filesize) when rasterized.
However, you might also try to embed the PDF in HTML page and load that HTML in the WebView - that may at least avoid the gray border/artboard.
webView.transform = CGAffineTransformScale( webView.transform, 1.25, 1.25 );
2 - Checking the Scale Pages to Fit box in IB sorted this for me
I would also like to know the answer to 1.
I guess you want to know how to display the PDF in the same way as when opening as attachment in mail, where the navigation bar only appears on a tap and the status bar also disappears?
You can also use Quartz to do it, as explained here : http://developer.apple.com/iphone/library/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_pdf/dq_pdf.html
Where has CGAFFineTransformScale been all my life?
Seriously, that is a big help. However, it worked better applying it to webView.scrollView.
Finally, is there a similar command to change the offset of the content as well as the scale?