I have a problem with stretchable images in my tableView.
Until Today I used static backgroundimages with 320px width.
But as I want to support landscape too, I thought I switch to stretchable images instead of using a seperate png file.
The first thing I noticed, was that the scrolling performance was really bad.
I didn't change anything else.
After that I started some time measuring, and removed everything from the drawing routine beside the stretchable image.
The "drawContentView" method needs factor 10 of the time, compared to using a non-stretched image with the same size of as the backroundRect.
With stretching the lags are easy to see. Without it scolls like a charm.
static UIImage *greyBackground = nil;
+ (void)initialize
{
greyBackground = [[[UIImage imageNamed:#"back_gray.png"]stretchableImageWithLeftCapWidth:65.0 topCapHeight:0.0]retain];
}
- (void)drawContentView:(CGRect)r {
CGRect backgroundRect = contentView.bounds;
[greyBackground drawInRect:backgroundRect];
}
Is the performance of this really that bad, or is something wrong here?
Tested on an iPhone 4, so should be powerful enough normally. :-/
I already thought about caching the correct sized image instead of the stretchable,
and recreate it with the new size after screen rotation.
But I know a lot app that use cell background images and different cell heights (e.g. Twitter a.k.a. Tweetie) and still scrolls amazing fast.
So, should it normally work better, or is stretchableImageWithLeftCapWidth something I better avoid?
I found a solution to solve the problem but still can't believe that this should be normal behavior of stretchableImageWithLeftCap:...
I sliced my backgroundPicture in 3 parts now.
- leftCap
- middlePart (1px width)
- rightCap
Left and right caps are drawn with drawAtPoint, middlePart ist drawn with drawAsPatternInRect.
Drawing this 3 cached images is more or less as fast as my original, fullsize backgroundImage was.
But I always thought stretchableImageWithLeftCap would do the same: Drawing 2 Caps and and 1px patterns between.
No idea why it's so slow for me.
Related
Environment:
I am creating a "photo mosaic" app, and I try to display 1024(32*32) pieces of small images(retina size->w:30px h:20px) on the screen same time. Which means on total, it is the same size as the full screen image size.
Issue:
I load 1024 UIImages, create 1024 UIImageViews, and add all of them to a UIView. When I scroll to this view, there is a big lag: test on iPhone4(iOS 5) and iPhone5(iOS 6). It's just appear on iPhone4, and on iPhone5 is fine. (Supposing iPhone5 have much more better CPU, so I think it is reasonable).
What I think:
Supposing all images have been already loaded from local dir in the memory(using method "imageNamed"), so I think the problem must be in the somewhere of the step display/render the images.
So any idea about it? Any, any idea will be helpful.
Thanks so much,
UPDATE
It is much better after I took the advice from #Antwan van Houdt . Here is the principle code:
-(void)updateCoverImageView:(UIImageView *)smallImage{
UIGraphicsBeginImageContextWithOptions(self.frame.size, NO, 0.0f);
CGContextRef ctx = UIGraphicsGetCurrentContext();
[self.coverImageView.layer renderInContext:ctx];
[smallImage.image drawInRect:smallImage.frame];
self.coverImageView.image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
}
Then you just set the alpha value of smallImage to zero, so the system won't render them. And the cover image will replace it. That works for the lag issue caused by displaying a large amount of UIView same time.
Is every image in its own view?
In either case, for such a huge amount of images you should probably consider drawing them in 1 view and if that drawing method is still too slow you could draw it once, render the view to an image and then simply draw that image as it's cached display.
There are several guides available from apple that deal with the performance of custom view drawing and stuff like it.. you should give them a read.
Not knowing the full details of your code, any thing like this, should be done on a background thread. I would read up on graphics contexts, grand central dispatch and then use both those concepts to create the resulting image in another thread and then get the resulting image and display it in the main thread.
Infact since you have many images which can all be processed in parallel, it can be done very fast using GCD.
If you can post the code, I can help you optimize it.
I'm having some performance problems with images in my app. I assign a UIImageView to the backgroundView property of a UITableViewCell. The Time Profiler instrument tells me that I'm spending most of my time here:
My table view has semi-transparent cells to let the background shine through. I know this is not good. But from what I can tell from the Profiler, this is not the bottleneck, right?
png_read_filter_row sounds like if there is some kind of expensive filtering going on.
Also down the bottom, there are 10.6% spent on transform_premul_argb_fn ... which sounds like some kind of scaling. My images are not scaled at all. I use them naturally (i.e. if the display needs 200 x 100, it gets 200 x 100. If it's retina, it gets a 400 x 200 version).
And finally, 6.7% on gzopen which sounds strange. My images reside in the Documents directory, not in the zipped App Bundle.
Maybe someone with deep Core Graphics knowledge can tell what those calls mean and how to avoid them?
Make sure your images are uncompressed after loading. Use the following code from http://markmail.org/message/vav7a5khncak2u3h
UIGraphicsBeginImageContext(image.size);
[image drawAtPoint:CGPointZero blendMode:kCGBlendModeCopy alpha:1.0];
UIImage *decompressed = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
I have a 5MP image coming from the back camera. I want to downsize it to put it into an ImageView without having to wait too long (it take a logn time to the UIImageView to display a 5 MP picture). So I tried many methods to resize / resample the image to make it fit a just-screen resolution (retina one). But it take around 1 sec to downsize the image.
Would you know any optimised way to be able to resize this 5MP image to the retina 960 x 640 resolution as fast as possible, and at least at less that 0.7 sec on an iPhone 4 ?
This is my favorite blog post and code to resize images. I haven't benchmarked it but I know of no faster way.
http://vocaro.com/trevor/blog/2009/10/12/resize-a-uiimage-the-right-way/
You're displaying an image in an UIImageView. I understand you want a version that is equal to the size of the screen. The way I would do it: display the original image in the UIImageView directly, this shouldn't take any noticeable amount of time.
Then in a background thread resize the same image down to the size you want and update the UIImageView as soon as that is done.
This gives you something on screen immediately while you generate an optimized version at the same time.
I don't know if you are using the original image for something else, but if you really only want the screen sized image it might be an idea to use an AVCaptureSession with a preset of AVCaptureSessionPresetHigh (see AVCaptureSession sessionPreset). This setting results in a more reasonably sized image, which might better suit your needs.
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)' : ')',
I am trying to capture the contents of a UIWebView including that which is not visible to the user. i.e. The whole web page even though the user is only looking at the top.
Looking around I found the best way to capture a UIView is to retrieve its layer and use renderInContext.
However, UIWebView seems to be using its own CALayer implementation which is behaving a lot more like CATiledLayer, although it is still claiming to be a standard CALayer. When I call renderInContext I only get one portion of the web page, up to 940px down, as opposed to the whole page.
Has anyone got any ideas on how to either: force the UIWebView to scroll down another 940px (obviously that is far from ideal) or tell whatever breed of CALayer it is backing the WebView to render all of its content when I ask it to.
Cheers
EDIT: I should add that currently change the frame of the webview to fit the size of the page retrieved through javascript.
I've released an app (Web2Pic) doing that, and please trust me that UIGraphicsBeginImageContext(webView.frame.size);
can do nothing except getting a small image from the visible area in our UIWebView ;-(
The right way is a bit complex but it just works:
1.Use JavaScript in our UIWebView to get these float values:
//Whole page size in HTML coordinate
document.body.scrollWidth
document.body.scrollHeight
//UIWebView visible size in HTML coordinate
window.innerWidth
window.innerHeight
2.Now we can 'cut' the whole page into dozens of UIWebView-sized small pieces. Then we can capture every small pieces individually and save them into our Cache. I implemented this by calculating page-offsets and use UIGraphicsBeginImageContext(webView.frame.size); to get a array of images. In addition, you should cache the image array into the file system, or the app will eventually crash!
3.When we finally got all the small pieces, we can start a full-resolution context: UIGraphicsBeginImageContext(CGSizeMake(document.body.scrollWidth,document.body.scrollHeight));
4.Render every small images into the big context based on the coordinates. And be careful to the corners, the last image in every line/row may not be a full image.
5.There is still one step left: saving the big image. Do not save it into the PhotoAlbum, because iOS will automatically cut down the resolution of images in the album. Instead, we can save it into the file system and enable the app's iTunes File Share support, or even write a simple in-app photo manager.
Hope these can help ;-)
Yichao Peak Ji
It looks to me like UIWebView renders on demand (witness the checkerboard as you scroll downwards rapidly on a large page), so there won't be anything in the part of the layer below what you can reach until the user scrolls down there. The layer won't be able to write out what it doesn't have, so I don't think you'll be able to capture the whole area.
As far as scrolling, there aren't any obvious exposed API methods that I can think of to move it down. The web view seems to host a UIScrollView or something similar, which you could try to access by traversing the view hierarchy and use its scrollRectToVisible:animated:, but that doesn't sound like a good long-term solution.
Just to answer one of my questions, you can scroll the view by using javascript.
So you use stringByEvaluatingJavaScriptFromString: with a javascript of window.scrollTo(0,%i);, where %i is where you want to scroll to. You can also use scrollY to retrieve the current scroll value.
Resizing the Webview is the way I solved it. If you want a bigger image with more detail, you just have to zoom in before calling this method. Beware that large dimensions could infulence the performance.
- (UIImage*) imageFromWebview:(UIWebView*) webview{
//store the original framesize to put it back after the snapshot
CGRect originalFrame = webview.frame;
//get the width and height of webpage using js (you might need to use another call, this doesn't work always)
int webViewHeight = [[webview stringByEvaluatingJavaScriptFromString:#"document.body.scrollHeight;"] integerValue];
int webViewWidth = [[webview stringByEvaluatingJavaScriptFromString:#"document.body.scrollWidth;"] integerValue];
//set the webview's frames to match the size of the page
[webview setFrame:CGRectMake(0, 0, webViewWidth, webViewHeight)];
//make the snapshot
UIGraphicsBeginImageContextWithOptions(webview.frame.size, false, 0.0);
[webview.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
//set the webview's frame to the original size
[webview setFrame:originalFrame];
//and VOILA :)
return image;
}
All UIViews have a size limit of 1024x1024, so you will probably have programmatically scroll, capture the page in chunks, and stitch them together somehow.
Set the height of webview equal to the contentsize of scrollview of webview.
-(UIImage *)captureImage:(UIWebView *)webvw
{
webvw.frame=CGRectMake(webvw.frame.origin.x, webvw.frame.origin.y, webvw.frame.size.width, webvw.scrollView.contentSize.height);
UIGraphicsBeginImageContextWithOptions(webvw.frame.size, NO, 0.0f);
[webvw.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *screenshot = UIGraphicsGetImageFromCurrentImageContext();
return screenshot;
}