iPad 2 Safari shows pixellated html text and images - ios

We are developing an HTML5 + CSS3 application for iPad and iPhone.
The app is working fine on iPad & all iPhones, however, iPad 2 shows html dom objects pixellated on startup, and stays like that, sometimes always, sometimes for a few moments.
App is designed for touch and gestures. We used translate3D for hardware acceleration on scrolling objects. We are also using jQuery (v1.7), but the scroller we designed is pure javascript, no frameworks there. jQuery is mostly used in finding/adding/removing dom objects and ajax. Except jQuery everything else is in-house written, including the jQuery plugins we are using.
As i said, animations are achieved by translate3D. For sliding effects we are changing the x or y axis values of the -webkit-transform, and when the touchend event is received, a momentum animation is achieved with javascript, -webkit-transition and translate3D. While app is being written, Apple's iOS Safari documentation is highly used as a guide.
Even though the app is working fine on iPad, iPod Touch (2nd gen), iPhone 3gs and iPhone 4, when it comes to testing on iPad 2 we started to see this pixellated screen. The strangest part is, the 3d accelerated content is the only part that gets pixellated. I've attached two screenshots, one from iPad, another from iPad2. You can see what I meant (they are taken in different times of the same day, so the content is different, sorry for that).
The main content (the boxes with images) can slide up and down with touch events. On iPad2, only this part is pixellated. While sliding, the pixellation stays most of the times, but on some tests it resets after a few seconds.
In addition, the html content has this line in :
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
We are starting the hardware acceleration through CSS, and the main sliding objects has this property :
-webkit-transform: translate3d(0,0,0);
For flicker proofing, images are not inside any dom object that has a background color, and has this property :
-webkit-backface-visibility: hidden;
For more flicker proofing on some cases we used this property (but the pixellated content in the screen capture does not have this one assigned):
-webkit-perspective: 0;
The app does not have 'apple-touch-startup-image' at the moment, so our first thought was that the startup capture ios makes is somehow messed. But it turns out that is not the problem, as after the content is downloaded via wi-fi, pixellation stays the same.
If anyone ever came across to this or a similar problem and was able to solve it, please answer as we have no other ideas left.
I tried to give as much information as I can, and here are the screenshots I've promissed:
iPad :
iPad 2 :

Try removing the transform and reapplying it immediately through a timeout:
$("#sliding").css("-webkit-transform: none");
setTimeout(
$("#sliding").css("-webkit-transform", "translate3d(0,0,0)")
, 0);

Related

jQM + WL on Android - High CPU in landscape

The current version of my app, running on Android 4.0.4 on an ancient Galaxy Tab has an odd issue when it's running in landscape orientation. I have the CPU usage developer option turned on, and I can see that a single core is being fully utilised when the app is sitting idle, even at it's login screen.
I'm using jQM 1.4.4, WL 6.2.0.01-20141027-1531.
When it's clear that CPU usage idling high for my app, I change to portrait and the CPU usage completely goes away, and the app is responsive again.
Step (CPU usage after a few seconds)
Login Screen (high)
Tap in text field, keyboard appears (none)
Hide keyboard (none)
Switch to portrait (none)
Switch to landscape (high)
On top of that, when I switch from Portrait to Landscape, the view doesn't redraw under the new aspect. The view is constrained to an area (square-ish) as wide as the screen is tall (or wide in portrait). The fixed header disappears but the view is interactive. To fix this, you can tap into a text field which brings up a keyboard. The view updates to fill the screen, and CPU usage is down again.
Other thing to note is that this issue did not exist in the previous version of the app. I've reviewed all changes between the versions and nothing stands out to me that should cause an issue like this.
Suspects:
the page or pagecontainer, popup or fixed header is doing a lot of work that usually should only occur on window resize (no direct changes to the logic here);
the CSS, in particular some responsive queries (there's a breakpoint between landscape and portrait) (no responsive CSS changes)
Other info:
Not a single problem was reported with Samsung Tab 3 running 4.2.2 or a Nexus 7 on 4.4.4 with this version
Tried using weinre to profile this issue except it loses connection soon after opening the app (again, previous version it was fine)
Minor differences between two identical target devices (Samsung Galaxy Tab 10.1): one tablet always performs fares better
I'm about to roll back to the older codebase and iteratively add code back in to see where the issue comes in.
Thanks for reading. Any pointers or suggestions are obviously greatly appreciated.
Update 1
I profiled from within Eclipse (turns out the Timeline inspector tab is pretty useless in weinre).
https://www.dropbox.com/s/ke0a9c2z9krhucu/highThreadUsage.PNG
Doesn't mean much to me. I suspect all that profile really says is 'the webview is doing all the work'.
I've created a new Hybrid app in the same project, and copied everything into it. I'm going to start stripping out chunks of code/functionality to see resolves the issues first.
This is a preliminary answer. I'm still doing the legwork and trying to see what exactly is happening in this situation.
The culprit appears to be a specific panel. A panel I haven't even touched in weeks. The only thing that I can even think of is that I changed the padding-top on .ui-tabs-panel from 1em to 0.5em...
There are two panels that are immediately init'd on app load. The one that slides from the right is the culprit: if I remove the init call and the HTML for it, the app is fine. Putting it all back, and prematurely opening the panel via weinre resolves the issue. Next step, is changing that padding-top back to 1em.
Problem doesn't show up. I repeat this several times over: make a build with 0.5em padding, and another with 1em. Repeat. The 0.5em build always has the issue, the other does not.
I'm going to chalk this up to the most coincidental (read: unlucky) bug, ever.
I'm planning on hardcoding the panel contents to display:none and showing them when the panel is opened. See if that works.

Simple Javascript Sprite Animation - line flicker, but only on iOS devices

There is a problem with the sprite animation on the homepage of one of my clients, but it only appears when the site is viewed on an iOS device, namely an iPhone or iPad. I can't replicate the problem on any other device or emulator, so I'm having an issue troubleshooting it (don't own an iPhone or iPad). The problem is: what looks to be a 1px line is appearing on the right edge of the animation frame pretty much all the time, and a similar line flickers occasionally at the top of the frame as the animation runs. The animation itself is a simple javascript sprite sheet animation. I'm operating under the assumption that I have the sprite animation programmed correctly since it appears correctly on every other device, platform and browser I've checked. It even works in IE.
Two questions:
What would cause a simple sprite animation to display differently when rendered by iOS?
As a small business consultant, I don't have the time and my clients don't have the budget for me to physically test on every single device, so I have to rely on emulators. What other options do I have if the emulators don't properly demonstrate what the device will display?
I'm not entirely sure of the protocol regarding posting a link to my client's production website, but happy to send a link to anyone willing to help that responds and/or messages me.
welcome to SO.
I spend a lot of time working specifically with iOS on the web and have run into similar situations. Without tweaking an example you post I won't be able to prove it exactly, but this should at least give you direction.
Flickering or semi opaque lines are often caused by the scaling set to the asset. In the world of high DPI displays and fluid layouts, there are differences in rounding that result in fine lines, shimmers, et al. Is there any scaling set on the assets, e.g. background-size, downsampling?
The emulators are displaying the software correctly - these issues are a result of hardware. Best thing you can do is buy a flagship for all of the platforms you test on, or look into local resources like Clearleft's Device Testing Lab

Weird pixels everywhere in phonegap

I'm developing a cross-platform application and I'm having a bug with only one of the test devices I have: The tablet HP Slate8 Pro (model 7600es).
The problem is that in many places of the display, there are weird pixels, like it doesn't get anti-alias-ed properly. Here are a few screenshots of what I mean:
The first one gets pretty clear. It's a part from a linear plot, and this green line just gets weird. Same for the circles.
The second one is harder to see, but there's a grey line in the middle that's also kind of broken, and the 8 and the second zero are not right
And finally, the last one is some text that's also wrong.
My viewport meta tag is:
<meta name="viewport" content="height=device-height, width=device-width,
initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
And my cordova version is 3.4.1-0.1.0
What's really strange though, is that the last app I made with cordova doesn't have this bug in the same tablet. The main difference between these two is that the old one was made with AngularJS and Bootstrap and this one is made with Ionic (That works on AngularJS as well). I don't really know if this could be related.
Also, testing this app directly in the Chrome browser of the same device, the bug doesn't show up. Then I think it only happens when using the cordova's WebView.
Anyone has any hint?
======= EDIT ========
I just found that putting target-densitydpi=device-dpi in the viewport meta tag "patches" this issue by disallowing density resize, thus making everything look way smaller than it should making my application almost unusable.
So, it really looks like the WebView is scaling all the webpage to match mdpi dimensions, but fails at anti-aliasing the resized pixels.
Probably I will post an issue to ionic.

iPad (3G models only) Safari crash

I'm using deck.js (http://imakewebthings.com/deck.js/) to recreate a company powerpoint presentation, using a fair bit of CSS3 animations and Javascript.
Testing through development on my wifi-only iPad2 it's been fine, but checking on a wifi+3G iPad1, 2, & 3 the page crashes Safari on page load (iPhone 4S works fine).
Some basic debugging (deleting slides one by one) suggests that it's the size of the DOM that is forcing the crash, as it works fine when I reduce the presentation down from 31 slides to 21.
The total size of the page is about 4.3MB, and I've tried using an appcache manifest to no avail.
I've read on various forums that many people are having issues with iOS 5.1 Safari crashing - does anyone have any experience of the iPad 3G models crashing under the strain of a complex DOM?
Any thoughts and suggestions much appreciated.
As is, it seems to be a limitation of deck.js on such devices. Martin Fowler reported the same problems and ended up loading slides incrementally as a workaround (http://martinfowler.com/bliki/Infodeck.html).
It would be helpful to see if the problem comes from loading the DOM or from displaying it (the default deck.js themes are not optimized for display efficiency). Unfortunately, I cannot test as I don't have an ipad, but what I would recommend to try and hide all slides and see if there is still a crash. Some CSS code to do that:
.deck-container > .slide:not(.deck-current), .deck-container > .slide:not(.deck-child-current) { display: none; }

iPad Limitations on Canvas Tag; Webpage Crashses on Canvas Tag Animation

Does anyone know if the iPad has any limitations on the canvas tag?
Currently I'm working on a creative that uses a flipbook and audio tag combination to simulate inline video content. The animations are drawn to the canvas element and synced with the audio content being played. There are 4 short video clips that get played when someone clicks on the four buttons below.
http://cs.sandbox.millennialmedia.com/~tkirchner/rich/K/kungfupanda2_test/
The problem I'm having though is in iPad. After playing a few animations, mobile safari just suddenly crashes. It never happens when I play it on my iPhone but it happens every time on the iPad. Its not one particular animation either because if I click a different combination of buttons, the previous clip that it crashed on plays fine, and then it decides to crash on another clip.
I think the problem might have to do with the amount of memory Safari gives individual page views. I found a blog post that explains that problem pretty well.
http://roblaplaca.com/blog/2010/05/05/ipad-safari-image-limit-workaround/
According to that post, once mobile Safari reaches a particular threshold of memory, images begin to return blank. This is consistant with my finds so far. The iPad that I'm testing this all on is running iOS 3.2.1 (and before anyone tells me that I should just explain to my boss that nobody uses 3.X anymore, I tried... they still want me to investigate this). I borrowed a co-workers iPad running iOS 4.2.1 and that device didn't crash, but some of the images weren't being drawn to the canvas.
I'm pretty sure its a problem with the canvas tag too, because I tried experimenting with running the animation without drawing anything to the canvas element, and the page never crashed.
Thats why I think maybe its a limitation with Safari's support of the canvas tag. Of course, I'm open to anybody else's suggestions.
Feels kinda weird answering my own question again, buuuut I figured if anyone did a search on this kind of question, an answer would be helpful.
I believe my original hypothesis was correct. The total amount of images that the aniamtions were using was around 600+. I think the older iPad loaded as many as it could and then when it ran out of cache and the canvas tag was trying to draw images that weren't really there anymore, it crashed.
Eventually we ended up serving the ad to devices with iOS 4.2 and higher, since the problem didn't seem to occur on those newer devices. Plus, we compressed the image sizes further, so that helped reduce the amount of images we were storing into memory.
If anybody knows approximately what the cache threshold in iOS 4.2 or higher browsers are, I'd appreciate it if you commented. Just want to get an idea of how many KB of image data I can safely load.

Resources