What's the fastest way to get a screen capture in flex? I am currently using: (I currently encode it to Base64 for upload to a webserver, but this is not necessarily required. All I want is an image file to appear on the server).
ImageSnapshot.defaultEncoder = JPEGEncoder;
var imageSnap:ImageSnapshot = ImageSnapshot.captureImage(<< flex component >>);
var screenshotData:String = ImageSnapshot.encodeImageAsBase64(imageSnap);
It currently holds up the entire application for almost a second as it actually captures the image. The Base64 encoding happens essentially instantaneously.
Check out the fllowing URL, it is an open source JPEG encoder which is over 4 times faster than the one in corelibs.
http://www.bytearray.org/?p=775
Take a look at the answer to this: Thumbnails of components
I've used a very similar function and it was pretty fast, so hopefully you'll have no problem doing it that way.
The open-source JPEG encoder is not any faster than the mx.codecs one, unfortunately. However, the build in PNG encoder is about 6x as fast as the JPEG encoder. This solves the problem that I was currently having, i.e. too slow compression.
The "thumbnails of components" answer from CookieOfFortune solves another problem, that of taking the snapshot separately from compression, (snapshotting takes ~5ms for me, compression, now, <500ms).
Related
I'm loading an image into my application and then converting that image to base64 data and then displaying it again (on an HTML page). But when I do that the colors are different! I'm using getPixel32 to grab the image data. I read somewhere that Flash uses precomputed values and that is the reason. I vaguely understood it. Can someone explain or link to an article explaining what is going on and how to fix it?
Snippet of code:
byteArray = bitmapData.getPixels(new Rectangle(0, 0, bitmapData.width, bitmapData.height));
Also, is it possible it's lost it's color profile?
UPDATE
I'm including the code I use to take a screen shot and convert it to base 64 data. http://pastebin.com/Q7MiWg9u
That's a very nice question! I'm posting this as an answer first because it's too long for a comment and second, because this article will at least help you understand what's the problem: http://www.quasimondo.com/archives/000665.php
Everything is because of the pre-multiplied alpha and the way Flash works with it.
I'm going to make a few small tests to see if you can actually fix this using getPixel32 and setPixel32, where you can use the unmultipleid values and calculate what's the actual ones that you need to set.
I have two ways to approach displaying an image on my webpage.
One way is a simple pass to the path of the image in src attribute.
Second way is to pass data in the src attribute
Will any problem occur in the future? Or a longer page loading time with second approach?
Suggestions please.
Loading the image in the page will be slower up front (larger html file), but faster overall (fewer requests to the server). Note that IE7 and lower have no support for this, and IE8 doesn't support images over 32k. (Source) Encoding in base64 also increases the image size by 1/3. (Source)
In my opinion, it makes sense for icons in CSS files, occasional small thumbnails, etc. But several large images should be loaded from normally.
If you have path: Use it.
First of all, data is not standard, so you can´t guarantee it works.
Second, you´ll get things like cache management free, without writing any code.
Yes the second approach is something like 8 times slower than the first one. That’s base64 encoding.
I use base64 to do small images, and the benefit of this is that they can be stored in a database. Use them on things like thumbnails, profile pictures etc... anything that is around 100 or 200 KB
EDIT: Sorry my bad... 37% bigger file size is base64
How can we speed up the process of loading hundred's of images in as3? it seams to be taking a very long time to load 100's of images.
If you don't have the ability to change the image quality or sizes, then there isn't a lot you can do to speed up such a large load, as you are limited by connection speed and simultaneous browser connections.
You may be benefitted by using a loading manager, like Greensock's LoaderMax. LoaderMax will help make sure you are loading several assets simultaneously - check out the maxConnections parameter.
Also, I suggest not loading everything up front with one preloader. Instead, have placeholders with a spinning loader for each image that then gets replaced by the final image once loaded. This will provide a much smoother user experience and create the illusion of the overall load taking less time.
100s of requests can take quite a long time even if the total size of the images isn't prohibitively large. If you know which images you need in advance, you could embed the images in another swf which you load at runtime.
By the way, what is the reason that you need to load 100s of images right away. Is there any reason you can't load them in the background a little more slowly?
A few suggestions:
Reduce the filesize of your images (obvious but most important).
Don't run all the requests at once - queue the images and load them one at a time (most relevant to least relevant).
There were lots of good advices already. But here a re my 2 cents. One day I had to load about 1000 of really small images. It was taking too long so I used FZip AS3 library. Worked like a charm.
The question does not provide a lot of specifics, so here are some general guidelines.
If the images are large JPEGs, you might be able to sacrifice some quality and recompress the images to make them smaller.
If the images are PNGs and represent, e.g., lots of small, individual tiles for a game, you could try combining many of them into a single image and then parsing them out into images on the client side after loading the image over the network.
Implement download queue, for example simple loader
https://github.com/hydrotik/QueueLoader
Do not load images that
currently out of stage (you can load them in background)
Use texture packer if you have plenty of small images
Optimize pics
quality (i.e. size, type)
Use cache, for instance Local Shared
Object, so for next time you'll get your pics ultimately fast from
LSO.
Is there any way to get thumbnails of the images made? If so, you could use the thumbnails while the larger versions load. Load all the thumbnails first (since they'd load really fast), then load the larger versions in prioritized order.
It sounds like you don't have a lot of control over the images, though. If you don't have any control there, there's very little you can do to speed up the process besides using a loading optimizer as others have suggested.
By linked images, I mean having an image in a directory and giving the path to the image in order to set an objects display or background. I've noticed that since using this method, my page is taking a considerable amount of time to load. So if this is the issue, what would be the alternative?
Thanks
I suggest using the Firebug addon for Firefox.
It breaks the loading time down and explains how long each thing takes to load.
But from your question i would say no, it shouldn't add any extra loading time on.
(I assume you mean loading an image from /index/pictures compared to /index/)
EDIT: Looking at your comments you say "more detailed image"... does this mean a larger file size and if so how large?
You can answer your question yourself by using firebug, We can't without asking a lot more questions since you have left so much needed information out. :/
Regardless of the location of the file, your browser still has to obtain the file. The key word there, is browser.
The data (regardless of type) is downloaded to the client (browser).
Regarding image size, try reducing image size, there are plenty of programs out there (I've found VSO image resizer rather useful in the past)
Remember, slow loading webpages effect SEO!
I have a project with only a couple of graphics and lots of ActionScript 3.
Anyone have any tips on reducing SWF file size?
First thing to do is turn on the size report (Don't have Flash handy, but should be in publish settings) and take a look at what is really taking up that space. From your description, it should mostly be in actionscript.
If you have any dynamic or text fields with embedded fonts, be careful you are embedding only the subset of characters you need, if you are using bitmaps, make sure you are using appropriate compression (lossless is actually better for 'computery' images, lots of solid colors or simple gradients).
As for reducing actionscript byte size... try the obvious things first: use publish or test instead of debug (Shift-F12 or Ctrl-Enter, not Ctrl-Shift-Enter) to compile release code, double-check that there are not flash built-in functions you can use instead of actionscript, use functions to share code, add local variables to reduce common sub-expressions.
You could try one of avoiding dynamic objects or using them more... each class has overhead for it's description, but I think they may have less overhead for member accesses. I have not tested this either way, though.
Either trim or copy out any methods you are using from other libraries. If you are using Flex... sorry, you are pretty boned :(. Watch out for class references that pull in a whole bunch of unused classes: making a trimmed private library copy is useful here as well.
If you are willing to sacrifice code quality: you could try using class members instead of parameters for deep call heirachies. Look out for inner functions - there are a few situations that can cause bloat. Since names are included (once), even using shorter package, class and member names (not parameter or locals), and literals instead of constants, so only the value has to be emitted, not the member name as well (I am not sure about private members, or in sealed classes).
Graphics should always be the first suspect in cases of file bloat. If you have images, reduce quality or size, or see if a different format yields smaller file sizes. Don't copy-paste vector drawings, put them in a movie clip or graphic and put that in other places. Also, if you have any sort of complicated vector art, smoothing can help reduce their complexity.
Action script can be reduced just as you would reduce any other code. Look for repetitions and other places that can be cut out. But honestly file size is not impacted much by code.
Somewhat related question: Why does my SWF file size not decrease when reducing content?
Runtime shared library
You can do couple of things..
save images as external links and load those dynamically(there is a trade off)
check SIZE REPORT , track down and trim down the large embedded files
Increase the compression of the graphics (such as lowering the jpg quality) and look for parts of your code that are not being used and see if you can trim or refactor.