Results 1 to 15 of 18
June 8th, 2009, 11:46 AM #1195Registered User
advice with loading very large images and retaining smooth animation
creating a slide show for a desktop app (will never be deployed on the web). The resolution is HD (1920x1080) and some of the images I'm using are even larger as I'm panning them and zooming them.
when I have an image on screen and I'm panning it or zooming it I load an image in behind it. The issue is every time the image loads in the background the image in the foreground that is moving stutters/skips for a split second and then continues on it's way. How can I avoid this hickup/dropped frame? BTW, this is all being done with code, no timeline animations.
note the images are being turned into bitmaps
I could try to preload the images with a bulk loader, but does it make sense to preload 40 + very large images every time the slideshow is instantiated?
Any thoughts are appreciated. Thanks
June 8th, 2009, 11:57 AM #215Registered User
if its never going to be on the web I'd be tempted to embed the images in the fla.
but if they do need to be dynamic then preloading might be the best bit.
Unless anyone knows a way round this sort of lock up?
anyone... bueller? bueller?
June 8th, 2009, 02:36 PM #3195Registered User
yeah, hmmm, the image folder is 116 mb large. eeeeek! Would be great to keep it dynamic, I guess once it's loaded in it's loaded in, I would be concerned that it would drain the cpu though, ok, gonna try to test a couple things now and will be back if I have answers, and will def be back if I don't
June 8th, 2009, 02:45 PM #4
Well if it won't ever be deployed on the web you could preload the images but keep them in the same spot the file is being locally accessed from right, a thumb drive or a cd or whatever. Having the images actually embeded in the flash file would probably bring compiling time up to a few minutes or so, that would be nasty.(Too many walls.)
June 8th, 2009, 06:46 PM #5195Registered User
so I tried a few things "quickly":
Preloading the images with bulk loader or placing the images directly in the fla itself did not produce any better results. As Saxx and I expected, compiling and preloading either of these methods took over a min each. Nasty indeed.
I even went through and removed all animations except the image panning and applied both the above methods, nothing better either.
my first conclusion, I suck at AS.
my second conclusion is that flash just can't handle placing 2320x1480 sized images on the stage without taking a deep breath. This is extremely frustrating.
I've read about some code to handle writing animations directly to the screen without actually playing them on the screen, kind of like playing them to the background and only writing the stage worth of content into a bitmapdata object that gets drawn to the screen. Does anyone know if this would be a viable option or would it more then likely result in me wasting more time. Remember I'm dealing with a HD 1920x1080 sized stage here.
many thanks for your thoughts.
June 8th, 2009, 07:02 PM #6
Every time i've used large images and flash there has been a bit of lag.(Too many walls.)
June 8th, 2009, 08:26 PM #7195Registered User
what program would you use? it needs to be integrated with flash as it's a slideshow for a touch screen display that allows users to browse content. Would AIR handle this any better? It was planned to have a slideshow that has 2 states, one for no interaction, and a state for when someone is interacting with it, hoping it would be dynamic. Maybe this needs to be re-thunk
June 8th, 2009, 08:59 PM #82320x1480
What are you using to Tween them - are you using TweenMax or TweenLite? If you're using the flash Tween methods, you might see some improvement with TweenLite.
If NOT tweening alpha or scale, then you might set the image container's cacheAsBitmap property
container.cacheAsBitmap = true; // might check if your container contains that property first (Sprite and MovieClip will)
If tweening the x,y values for you're panning, you might play with tweeing the scrollRect property of the container (if it's a MovieClip or Sprite). I can almost guarantee a performance increase using this method. Basically you set:
var _rect:Rectangle = new Rectangle(x,y,width,height);
container.scrollRect = _rect;
Then, you can use TweenLite to tween the properties of the Rectangle - TweenLite can fire and event when motion changes, in which, you'd update container.scrollRect = _rect;
Hope these help
June 9th, 2009, 12:54 AM #9195Registered User
I'm using greenshock, tween max, version 10, from what I understand tween lite is obsolete with version 10, but please correct me if I'm wrong or misunderstanding something.
Sometimes I am scaling and alpha fading, I'll try a version without that and caching the bitmap.
the code for this will be:
bitmap = Bitmap(loader.content);
bitmap.smoothing = true;
bitmap.cacheAsBitmap = true;
is caching the bitmap and moving x,y better then not caching and zooming or fading? I really need/wanted both but I can get around it for now.
Never thought to use scroll rect, that might just be brilliant enough! I'm panning both x and y, maybe I should also try just panning one direction... There is some discreptency on the adobe docs on how to best go about this, why don't they just provide the correct answer is beyond me, so I may need some help here. I'm gonna try this as well as re-optimizing the images and caching the bitmap and let you know if it works with loading images in.
Loading off the desktop/locally doesn't seem to be any different then preloading or adding them directly to the fla, but please let me know if I'm extremely way misinformed here.
I'll be back...
June 9th, 2009, 01:13 AM #10
yeah, if you could avoid the scaling and alpha, that's probably going to help quite a bit I'd presume - a lot of it depends on the computer speed too, of course. You might try a transition where a colored sprite alpha fades over the images to transition them - alpha on large rasters, especially when moving above another raster really can chug on computers. Loading locally, I don't think that should matter too much, You may try to preload all images first, before animating as well. And only add the currently animating images to the stage, if you have them all stacked, that's going to impact things as well I believe. If you're animating/loading at the same time that may help. Scaling and using scrollrect at the same time will be a bit tricky, when you start playing with that you'll know what I mean. good luck with!
June 9th, 2009, 01:18 AM #11195Registered User
well that was so much easier to implement then I thought, I can't even believe it!!!!! I mean I was ecstatic, and still am!!!!!
I must say the performance was increased 1.5 fold, I actually had to slow down my animation!!!
I still get the hickup, granted it is not quite what it was before, it is still not perfect.
in the end I optimized the images to an unacceptable degree, only dealt with x,y movements and used the scrollRect. FPS stayed at about 30, while when I was using my before method it wavered between 14 and 30. The image load is till heavy though, but it's really really close. I might be able to work with it, but since I'm a designer there is not almost, it has to be perfect!
Thanks for the comments, you guys are the best!
anything else is hugely appreciated, I'll keep testing and refining to see if something comes out of it. Be bak soon!
June 9th, 2009, 01:26 AM #12195Registered User
your comment about scalling the scroll rect has me a bit concerned. In my mind I feel it should be simple, apply the scale to a var, and use it to redraw the scroll rect in the opposite scale, just math. But I may be missing something which may actually help what I'm workoing with now.
1st I move the image, then I use a listener from the "onUpdate" to update the scrollRect's possition by the opposite amount, then I draw/apply/(whatever the heck is happening) the scrollRect to the image being moved, then it repeats.
Am I loosing performance by redrawing/calculating on every update?
June 9th, 2009, 01:37 AM #13
Cool - cacheAsBitmap is a biggy, if you run an alpha or scale test with that turned on, you'll definitely see the impact. You'll have a tiny bit of loss due to the constant code updates, but scrollRect works like a really efficient mask - anything beyond the rectangle bounds isn't rendered visually, it's in basic terms ignored. If you scale the container though, things get whacky as far as xy if I recall, I've had a pain in the past using scroll rect and scaling but it works. for movement speed comparison, if you want an example, this link has quite a large raster image similar to yours granted compress for the test, that does scale, when scaling cacheAsBitmap is turned off, when done scaling, it's turned back on, but the entire motion is handled via scrollRect. click on toggle scalability - then drag the blue box - it's quite responsive compared to using a mask, or just letting the stage become the "matte" boundry.
June 9th, 2009, 11:58 AM #14195Registered User
your sample looks real good. So I'm having more trouble then anticipated getting the scrollRec to crop a moving image at the desired x,y. Any hints you can offer? Do I need to calculate the rate of change?
June 9th, 2009, 12:27 PM #15
you'll have to set this fla next to your gs folders - hope this example helps: