I have a SVG sprite I am loading into both my regular and mobile sites. The SVG is 74kb.
When loaded in the normal site on a New iPad(v3) iOS 5.1(9B176) there are zero scrolling and zooming issues whatsoever. There a 24 instances where a portion of the sprite is displayed.
When I load the same SVG into the mobile site on a iPhone 4 iOS 5.1(9B176) I get a significant lag in scrolling up and down when I lift my finger. If I leave my finger on the screen there are no scroll issues. Ther are only 16 instances where a portion of the sprite is displayed. If I replace the SVG with a #2x PNG (152kb) I have no scrolling issues. On the mobile site there is no zooming, since the viewport is set to user-scalable=0.
I was wondering what the issue could be and why this might be happening. Any insight would be greatly appreciated.
Thank you.
As soon as I add CSS transform or blackface-visibility it starts to flicker and lag at the end of zooming/scrolling when it redraws. So try to remove any CSS animation you have on the page and see if it has any impact.
Related
I have come across an unusual problem related to animated gifs on both the ipad and iphone on both safari and chrome and have been unable to find any posts with a similar problem.
Through a series of tests I have found that if the animated gif is over 480 pixels wide it will not play but stay on the first frame. You can view a test page here: http://www.echo3.com.au/test/animation/. They all play fine on desktop computer in all browsers.
Has anyone else had this problem as I am baffled by it?
I'm using a full screen UIWebView to house/render an HTML5 application under iOS. Very much like Cordova/phonegap although I'm not using those. I try to make my webview size match the underlying display. Unfortunately, on retina displays, the value returned by self.view.bounds relies on the UIScreen scaling factor. So I get 1024x768 instead of 2048x1536. Not a huge problem except I then instantiate the UIWebView using the smaller bounds (after adjusting for the status bar) and some things get a bit jaggy. In particular, I use canvas at a couple of points and also rounded borders appear thick. To be clear, this isn't a case of scaled raster resources.
I'm not getting the full resolution of the screen using that UIWebView. Ideally, I'd like to set the screen scale to 1.0 but that doesn't appear to be supported. Any suggestions on how best to get full advantage of the screen?
The problem is most noticeable on the iPhone 5 simulator. I don't have that hardware to test on. iPad/new iPad I think has the problem but the jaggies aren't as noticeable.
Update: The more I look at this, the more I think it may be restricted to canvas.
Solution: In case anyone else gets here. Based on the answer below, I created all of my canvas elements with width and height multiplied by window.devicePixelRatio and then set their style attribute to have the original (device independent) size.
See https://stackoverflow.com/a/7736803/341994. Basically you need to detect that you've got double resolution and effectively double the resolution of the canvas.
I've been working on an iPad app that has gone through fairly extensive testing on the iPad 2. I recently obtained a "New iPad" (iPad 3), and the app feels significantly slower. Animations / scolling behaviors that were silky smooth in the iPad 2 now feel extremely stuttery on the new iPad.
I do a lot of the standard UI performance tips: using shadowPaths, drawing UITableViewCells using CoreGraphics, rasterizing views that don't change often / don't need to animate.
Are there any pitfalls I should watch be watching out for in transitioning my app to the iPad 3?
Update
I swore that I tried this before but removing rounded corners from my UIViews views ended up speeding the app significantly. clipToBounds also seems to be a significant performance hit (although strangely... setting a view's layer's maskToBounds seems to be okay, which makes no sense to me). Some combination of this and other tweaks seems to have resolved the issue.
Once I do a second visual pass over the app, I'll figure out a way to reimplement rounded corners in a more performant way.
4x the pixels, only 2x the fill rate. The maths says it all.
I think that the biggest thing to watch out for is copies of graphics from system memory to the video card since they are 4X larger than previous iPad graphics with about the same CPU power as the iPad 2.
Maybe it's due to upscaling by iOS? After all it has to calculate a higher res version of everything before showing to screen. Since some things on the screen are hi-res already (font and default ui elements) it has to scale every other element individually.
Have you tried just scaling the images yourself and adding them as retina images to your project?
Good luck.
I am trying to integrate a zoom/pan capability into an image gallery for iPad (implemented with Flash builder 4.5 and Air mobile sdk), which is pretty simple on the paper, using gesturezoom handling and scale on the displayed image.
My problem is that I have some medium & high resolution images (about 4096*3072, 5Mo photo), and that zoom/unzoom seems to freeze a lot on the iPad upon the first initial gestures. After a while, everything goes smooth (or kind of smooth :-).
Does anybody know what is the reason of these freezes, and how to solve this?
Thanks a lot,
Antoine
I would suggest working with the BitmapData of the image and blit to a container the size of the screen. The Matrix class can help you to scale the BitmapData you are drawing to your container and you can change the size of a Rectangle as your scaling gesture events occur to bring in more pixels from the source image. That way you're never displaying more than the amount of pixels that fit into your container at any given time.
I'm currently working on an OpenGL game, and recently began refactoring it to support iPhone in addition to iPad. In an attempt to give myself as little work as possible, I simply resized the containing EAGLView to 480 x 360 (to preserve the iPad aspect ratio) and shifted the view up so it's y origin lay at -20 (in order to centre the content, and as the edges could be cropped).
I found this resulted in jerky performance on the device (despite the CADisplay link reporting a frame duration that equated to 59-61 fps) and was at least 20% slower when compared side by side with the iPad version.
I then tried resizing the view to the screen size 480 x 320 and the performance returned to normal (though the rendered content no longer has the correct aspect ratio).
Why is it that the 'off screen' rendering causes a performance hit and why does the displaylink still think it is running at 60fps?
Any ideas?
Thanks
This is mostly a wild guess, but what about clipping regions? There was this hardware functionality that made it possible to mix windows and hardware accelerated graphics. Maybe it is not implemented very well on mobile devices.
You could, however, avoid making the UIView offscreen and try to use glViewport() to shift the parts of the view offscreen. While it seems to be the same, it is handled by a different part of the pipeline (the rasterizer), and should be much faster.