The forums have permanently moved to forum.kirupa.com. This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.


Page 1 of 2 12 LastLast
Results 1 to 15 of 18

Thread: advice with loading very large images and retaining smooth animation

  1. #1
    195
    posts
    Registered User

    advice with loading very large images and retaining smooth animation

    my scenario:
    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.

    my problem:
    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

  2. #2
    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?

  3. #3
    195
    posts
    Registered 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

  4. #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.)
    http://saxxdev.com

  5. #5
    195
    posts
    Registered 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.

  6. #6
    Quote Originally Posted by emolen View Post
    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.
    haha wow. Yeah man i don't know if this is an option, but maybe you're not using the right platform for a slideshow. It sounds like you'll be using hack after hack, i don't know. I'd say if you time scrap it and work with something that's better for slideshows or even a program specifically for them.

    Every time i've used large images and flash there has been a bit of lag.
    (Too many walls.)
    http://saxxdev.com

  7. #7
    195
    posts
    Registered 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

  8. #8
    2320x1480
    Moving images of that size is definitely going to Tax the player when they're tweening, mainly with scaling - but there are some ways to try to increase performance:

    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

  9. #9
    195
    posts
    Registered 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;
    addChild(bitmap);

    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...

  10. #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!

  11. #11
    195
    posts
    Registered 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!!!

    BUT..........

    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!

  12. #12
    195
    posts
    Registered 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?

  13. #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.

  14. #14
    195
    posts
    Registered User
    @ creatify

    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?

  15. #15
    you'll have to set this fla next to your gs folders - hope this example helps:
    Attached Files Attached Files

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Home About kirupa.com Meet the Moderators Advertise

 Link to Us

 Credits

Copyright 1999 - 2012