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.
Related
When working with NPAPI, you have the control over two functions: NPP_WriteReady & NPP_Write. This is basically a data push model.
However I need to implement support for a new file format. The library I am using takes any concrete subclass of the following source model (simplified c++ code):
struct compressed_source {
virtual int read(char *buf, int num_bytes) = 0;
}
This model is trivial to implement when dealing with FILE* (C) or socket (BSD) and other(s), since they comply with a pull data model. However I do not see how to fullfill this pull model from the NPAPI push model.
As far as I understand I cannot explicitely call NPP_Write within my concrete implementation of ::read(char *, size_t).
What is the solution here ?
EDIT:
I did not want to add too much details to avoid confusing answer. Just for reference, I want to be build an OpenJPEG/NPAPI plugin. OpenJPEG is a huge library, and the underlying JPEG 2000 implementation really wants a pull data model to allow fine access on massive image (eg: specific sub-region of an 100000 x 100000 image thanks to low level indexing information). In other word, I really need a pull data model plugin interface.
Preload the file
Well, preloading the whole file is always an option that would work, but often not a good one. From your other questions I gather that files/downloads in question might be rather large, so avoiding network traffic might be a good idea, so preloading the file is not really an option.
Hack the library
If you're using some open source library, you might be able to implement a push API along or instead of the current pull API directly within the library.
Or you could implement things entirely by yourself. IIRC you're trying to decode some image format, and image formats are usually reasonably easy to implement from scratch.
Implement blocking reads by blocking the thread
You could put the image decoding stuff into a new thread, and whenever there is not enough buffered data already to fulfill a read immediately, do a blocking wait for the data receiving thread (main thread in case of NPAPI) until it indicates the buffer is sufficiently filled again. This is essentially the Producer/Consumer problem.
Of course, you'll first need to choose how to use threads and synchronization primitives (a library such as C++11 std::thread, Boost threads, low-level pthreads and/or Windows threads, etc.). There are tons of related SO questions on SO/SE and tons of articles/postings/discussions/tutorials etc. all over the internet.
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
I have to download some info from the Internet, like what's the phone number of a person. I want to save the info in disk in order to load it when my application starts. So I want to know whether Core data is the best choice? I mean is it fast enough? I want to load the info into NSCache object, is it a good class I can use?
It is a Plist type caching; key->value, only strings. Easy coding. For a few data I would recommend this. described here
The other one with NSArchiver->NSData: binary storage, any type of data, but you have to deserialize and deserialize. More coding, no limits ( well, you are doing the transformation) . I do proffer this one, because during the development, maybe I will need later some other data than text. Usually need to cache images. presented here actually the good answer is with downvote!
If you are storing anything that will be used between launches of the application then using Core Data is the way to go unless you have really, really basic requirements. NSCache is better as a temporary cache that is used by the application as it is running and for data that can be recalculated if it does not already exist.
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 am writing a scriptable game engine, for which I have a large number of classes that perform various tasks. The size of the engine is growing rapidly, and so I thought of splitting the large executable up into dll modules so that only the components that the game writer actually uses can be included. When the user compiles their game (which is to say their script), I want the correct dll's to be part of the final executable. I already have quite a bit of overlay data, so I figured I might be able to store the dll's as part of this block. My question boils down to this:
Is it possible to trick LoadLibrary to start reading the file at a certain offset? That would save me from having to either extract the dll into a temporary file which is not clean, or alternatively scrapping the automatic inclusion of dll's altogether and simply instructing my users to package the dll's along with their games.
Initially I thought of going for the "load dll from memory" approach but rejected it on grounds of portability and simply because it seems like such a horrible hack.
Any thoughts?
Kind regards,
Philip Bennefall
You are trying to solve a problem that doesn't exist. Loading a DLL doesn't actually require any physical memory. Windows creates a memory mapped file for the DLL content. Code from the DLL only ever gets loaded when your program calls that code. Unused code doesn't require any system resources beyond reserved memory pages. You have 2 billion bytes worth of that on a 32-bit operating system. You have to write a lot of code to consume them all, 50 megabytes of machine code is already a very large program.
The memory mapping is also the reason you cannot make LoadLibrary() do what you want to do. There is no realistic scenario where you need to.
Look into the linker's /DELAYLOAD option to improve startup performance.
I think every solution for that task is "horrible hack" and nothing more.
Simplest way that I see is create your own virtual drive that present custom filesystem and hacks system access path from one real file (compilation of your libraries) to multiple separate DLL-s. For example like TrueCrypt does (it's open-source). And than you may use LoadLibrary function without changes.
But only right way I see is change your task and don't use this approach. I think you need to create your own script interpreter and compiler, using structures, pointers and so on.
The main thing is that I don't understand your benefit from use of libraries. I think any compiled code in current time does not weigh so much and may be packed very good. Any other resources may be loaded dynamically at first call. All you need to do is to organize the working cycles of all components of the script engine in right way.