I am using CGContextDrawPDFPage class to render PDF in my app without any trouble. But, the amount of time taken to load the book is a bit more and the time taken to render the page is proportional to the number of pages in the PDF.
In my case, the PDF can contain anywhere between 500 to 1000 pages. Due to this, the loading time of my PDF is getting increased. It is almost taking 10 seconds to render the first page which is really bad from a user experience aspect. And this time is being taken only during the loading of the book for the first time. In my opinion the delay is due to the fact that i am trying to read the entire PDF at once.
Is there a way in which i can read the PDF part by part so that the initial time to render the PDF is faster.
Thanks.
Have you run Instruments to see where the time is spent?
I suggest you use heavy pre-caching to solve the problem. In my experience, analyzing the PDF (for aspect ratio stuff, annotation, etc) takes some time. Drawing is slow too.
I solved this with pre-generating images on the fly, and showing them whenever possible. Of course this is tricky too, e.g. don't ever try to render on and off screen at the same time, memory usage while drawing a complex pdf is off-scale and performing two operations at the same time may just crash your app.
Related
I'm working on an iPad-only iOS app that essentially downloads large, high quality images (JPEG) from Dropbox and shows the selected image in a UIScrollView and UIImageView, allowing the user to zoom and pan the image.
The app is mainly used for showing the images to potential clients who are interested in buying them as framed prints. The way it works is that the image is first shown, zoomed and panned to show the potential client if they like the image. If they do like it, they can decide if they want to crop a specific area (while keeping to specific aspect ratios/sizes) and the final image (cropped or not) is then sent as an email attachment to production.
The problem I've been facing for a while now, is that even though the app will only be running on new iPads (ie. more memory etc.), I'm unable to find a method of handling the images so that the app doesn't get a memory warning and then crash.
Most of the images are sized 4256x2832, which brings the memory usage to at least 40MB per image. While I'm only displaying one image at a time, image cropping (which is the main memory/crash problem at the moment) is creating a new cropped image, which in turn momentarily bumps the apps total RAM usage to about 120MB, causing a crash.
So in short: I'm looking for a way to manage very large images, have the ability to crop them and after cropping still have enough memory to send them as email attachments.
I've been thinking about implementing a singleton image manager, which all the views would use and it would only contain one big image at a time, but I'm not sure if that's the right way to go, or even if it'd help in any way.
One way to deal with this is to tile the image. You can save the large decompressed image to "disk" as a series of tiles, and as the user pans around pull out only the tiles you need to actually display. You only ever need 1 tile in memory at a time because you draw it to the screen, then throw it out and load the next tile. (You'll probably want to cache the visible tiles in memory, but that's an implementation detail. Even having the whole image as tiles may relieve memory pressure as you don't need one large contiguous block.) This is how applications like Photoshop deal with this situation.
I ended up sort of solving the problem. Since I couldn't resize the original files in Dropbox (the client has their reasons), I went ahead and used BOSImageResizeOperation, which is essentially just a fast, thread-safe library for quickly resizing images.
Using this library, I noticed that images that previously took 40-60MB of memory per image, now only seemed to take roughly half that. Additionally, the resizing is so quick that the original image gets released from memory so fast, that iOS doesn't execute a memory warning.
With this, I've gotten further with the app and I appreciate all the idea, suggestions and comments. I'm hoping this will get the app done and I can get as far away from large image handling as possible, heh.
I'm currently working on a picture-sharing app on iOS, and my developer is struggling mightily with managing memory. I would really appreciate some help.
Take this "user feeds" module, my developer can't design a scroller that maintains a smooth scroll unless much of the thumbnails are preloaded before scrolling starts. This expectedly makes the initial loading experience much longer than desired. He used server-side compression which further compresses IPhone images (originals were around 2mb) that were already compressed to 200kb on the iOS side down to around 20kb. The end result is a highly blurry low-quality thumbnail, especially displayed at the size seen in the video.
https://dl.dropboxusercontent.com/u/76154448/Scrolling%20Down%20Only%20Works%20With%20Highly%20Compressed%20Thumbnails%20and%20Needs%20Pre-loading%20to%20Ensure%20Smooth%20Scrolling.mp4
He originally just used a cropped version of the underlying image as the "thumbnail," but with each picture being 200kb, 10 "thumbnails" loaded is already 2MB of memory used. Another 2MB is being used on thumbnails of user avatars, since those were not yet compressed by the server. We designed the feed, like many other picture apps, so that more images can be loaded by scrolling down.
My questions are this:
What is a good technique to do server side compression of thumbnails without quality loss? How does an app like Streamzoo do this?
https://dl.dropboxusercontent.com/u/76154448/Smooth%20Scrolling%20with%20Streamzoo.mp4
What is a good technique for managing the increase in live bytes? How do picture apps like Pic Collage manage to show up to 200 thumbnails while seemingly keeping every image cached without crashing?
Any responses are greatly appreciated!
He's probably creating all UIImageViews once the server responds. He could use UICollectionView to lazy load views, so only a few of them would be on memory on the same time.
I wrote an article about performance tips and tricks, and this one is covered there.
Hi every one Recently I achieved thumbnail image(png) creation from the pdf and you can see the Thumbnail creation from PDF post Now my problem is, It is taking time to create a thumbnail images when compared to download thumbnails from the server through wifi.Is there any better way to create the thumbnails bit faster.
I notice you have the interpolation quality set to high. If you set it to low, it will likely render faster.
When developing a mobile app, and letting the user take photos (That later will be shown in full size also) but are also viewed in the table views (mid size) and even in the Google maps pin title view, Should I create a thumbnail/s for every image the user take for the smaller ones? or should I just use the regular image?
I am asking because From the tutorials i saw, and as a web developer, all I could figure out is that when using a web service to get groups of small images you usually get the thumbnails first and only when needed get the Full size image.
But this is an embedded (I know it is not embedded, but i don't have a better way to describe this) app, that all the data sits on the device, So there is no upload performance issues, just memory and processor time issues (loading to view the big HD photos that the cameras take today is very heavy I think.
Any way, What is best practice for this?
Thank you,
Erez
It's all about memory usage balanced with performance. If you don't create thumbnails for each photo, there are only so many photo you can hold in memory before you receive memory warnings or have your app terminated by the system (maybe only 6-8 full size UIImages). To avoid that, you might write the photos out to the file system and keep a reference to their location. But then your tableview scrolling will suffer as it attempts to read photos from the file system for display.
So the solution is to create thumbnails for each photo so that you can store a lot of them in memory without any troubles. Your tableview will perform well as the photos are quickly accessible from memory. You'll also want to write the full size photos to the file system (and keep a reference to their location) to avoid having to store them in memory. When it's time to display the full size image, retrieve it from the file system and store it in memory. When it's no longer needed, release it.
I'm assuming that you're in iOS4, and you are saving the photos in the Asset library, there is already a method for you.
http://developer.apple.com/library/ios/#documentation/AssetsLibrary/Reference/ALAsset_Class/Reference/Reference.html
You're looking for the "thumbnail" method.
So, save the large image, and compute the thumbnail when required, I believe, is the way to go.
I'm making a bandwidth test in flash, and I want to display a progress bar and the current calculated speed. For the download part this is pretty straightforward, but for the upload part it gets a bit trickier.
As I've understood the only way to track upload progress is by using FileReference. But as I'm uploading a dynamically generated ByteArray, it seems FileReference isn't usable either.
So one idea I had, was just uploading a ByteArray of say 100-200 kB, and calculate the speed of that upload, then fake a progress bar based on that speed, when uploading a larger ByteArray. But then again it would probably be way off under some circumstances, and calculating the current speed would be difficult.
So I need some ideas on how to solve this :)
Best way is to look at code that already does this. Go here to see an example. View source is enabled so right-click and look at what they're doing.