I'm working on a Flash GUI project which has many images need to be dynamically loaded at runtime.
Problem:
Currently everytime a class initializes, it loads its assets (images) from HDD, but that usually takes too long (for example: I have a list of 100 items, each item has the same background, which is a PNG image stored on HDD, but it has to load the image 100 times from HDD to render the list, because the item's class gets to be initialized 100 times). Also, I want assets to be hidden from the users, so I want to pack it up somehow, into a single file.
Solution:
I think of SWC. I heard it's sort of library for Flash. But I have almost no experience on working with SWC. And there are too many images, would take very long to manually import and put class name for each of them in the FLA library. But I already have an XML file which stores the class names and the path to each class' assets. So I can load all the images into a variable, but I don't know how to actually write that variable into a SWC file on HDD to load it later as a library.
[MyButton.png] --load to RAM--> [myButton:Bitmap] --write to SWC file on HDD--> [Assets.swc] --import the SWC file at runtime--> [addChild(assets.myButton)]
The text in bold is the part I'm missing.
Thanks for your time! Any help is greatly appreciated.
SWC is a file that you "precompile" it's pretty much the same as a swf, but really nothing that you "create on the fly". The biggest difference is that a swc is something that is "compiled into" an swf and not loaded dynamically. That is, you can't load a swc-file during runtime, it is provided during compile time.
So, every picture added to the swc will increase its' size, the good thing is that it can be shared between different swf-files.
Now, correct me if I understood you wrong, but it seems like you reload the picture from hard drive whenever that picture is used? So 100 instances of "Ball" which is linked to the picture "Ball.png" would load that file 100 times?
If that is the case, why not just create an ImageManager and let that one keep one instance of the loaded images and then share it among all the instances that uses that image?
AFAIK there is no easy way to do this, however I wrote a blog post (since I couldn't find a better way to give you that solution) if you are interested in an example with caching loaded images.
It's pretty naive and revolves around a static ImageManager, loading only images, caching them by their url-id and then providing a new instance of the bitmapdata if they are allready loaded. However, it works like a charm and it is WAY MORE efficient than always loading the image from hard drive.
You can find the blog post here: http://messer1024.blogspot.se/2012/12/caching-loaded-images-in-as3.html
Related
I have to work with some rather large images and multiples of them. During my testing I test uploaded several which I didnt apply to an actual object. Now It says I have taken up .7% of my 20 gigs with only 3 images on an object.
Does parse keep all images I uploaded previously even though I never applied them to an object? Is there a way to clear this data out?
Yes, it still counts against your storage, because the file is still there even if you haven't saved a reference to it on a ParseObject. You can clear out files that have not been assigned to Parse Objects by going into the Settings page and scrolling down to "Clean Up Files".
I've spent hours googling and referenced all the livedocs but can find no objective comparison between the 2 following methods to load images
1 Loader with loaderContext=ImageDecodingPolicy.ON_LOAD
as per this example
http://www.bytearray.org/?p=2931
and
2 URLLoader using URLLoaderDataFormat.BINARY and Loader.loadBytes
Could anyone possibly shed some insight as to which is better-quicker?
Loader is in a way an extension of URLLoader. If all u need is a binary for storage then use URLLoader. However, if binary needs to be decoded, you'd be better off using Loader, because you will need it anyway, even if you use the URLLoader to load the binary. With policy of ON_LOAD the decoding will take place in another thread.
I've a problem with a document-based project in Cocoa. I've searched for a while but I didn't find anything which seems to resemble my goal. What I want to do is a (computation intensive) simulation program which generates a lot of data (probably in the order of GBs) and store them to the disk for a future visualization (so I cannot write/read the files all at once).
I created a document-based project (I don't know if it is the way to go...) with the idea to save all the data in many binary-files within a package, so the user can see it as a single file. I have already tried that part and I was able to save the document with NSFileWrapper. But the simulation-files are generated as the simulation is running. And here comes the problem.
There is a way to force the user to save the document and retrieve the path so I can put there all the files generated? Or it's best to save the simulation-files in a temporary location and then save the document periodically so that it saves all the files ready for saving? Or what can I do? It's not clear to me the usage of the nsdocument architecture in this case and what it's a good way to achieve my goal.
The document has also another couple of files in which there are the simulation parameters and the initial state, so I can resume the simulation at a later time.
I'm using FPDF with PHP and need to print an order manifest. This manifest will have up to 200-300 products with images. Creating it at this point is quite slow, and the images are stored on AmazonS3. Any idea if this could be sped up?
Right now just with images of about 15X15 mm it generates a file size of about 16mb and takes 3 1/2 to 4 minutes, which without the images is only about 52k and comes up almost instantly.
Of course, it may just be downloading that many images about which there's not really much I can do.
I suggest you to try img2pdf.
While this module offers much less options for interacting with PDFs compared with fpdf, if you are only interested in combining images into a PDF file, this is probably the best module you can use. It is fast. It is easy to use.
Here is an example code:
import img2pdf
filename = "mypdf.pdf"
images = ["image1.jpg", "image2.jpg"]
with open(filename,"wb") as f:
f.write(img2pdf.convert(images))
I used it to combine 400 images - it only took a second or so.
I found the extension i mentioned in my comment above:
http://fpdf.org/en/script/script76.php
this seems to reduce the time it takes a little for myself, you may have better results as your document is much larger than mine.
I'm new to Core Data and I'm working on my first personal iOS app.
I have an entity, lets call it Car, which has a thumbail as well as a gallery of other images associated with it. The data is synced to an online service using ASIHTTPRequest and JSONKit. The app doesn't need to create new Car's, just display them.
The thumbnail could be around 100kB so I may store that as blob data within the Car entity.
However I'm not sure how I should store the other multiple images?
The images would be around 800kB to 1MB each using so storing them in the Core Data store doesn't seem to be recommended.
The only options I can think of are:
Store the url of each photo within another entity CarImage and rely on ASIHTTPRequest's cache.
Create a folder structure and save each image into it's corresponding Car's folder and keep references to the file path in the CarImage entity
Because the data is synced, there is the potential for Car's to be deleted, so images in folders would have to be deleted as well. I can see this getting out of hand pretty quickly.
I would appreciate any advice. Thanks.
I'd take your first option.
Regarding the images that would have to be deleted: isn't that taken care of automatically by ASIHTTPRequest's cache, once they expire? At least that's what I'd expect from a cache...
I'd go with the first option. I've done something similar in the past, though I actually did store the image binary data in Core Data as well. I wouldn't recommend storing the data, though, as this caused problems for me - just rely on ASIHTTPRequest's cache.