Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

About Last Update 01-06-2010

Recommended Posts

Hello everyone, and Jack.


I just received the latest update via email, and I dislike the change in item 1, which is:


1) ImageLoader's and SWFLoader's "content" property always returns the Sprite Which now serves as a container for the remote content. This is Sprite Immediately available, making development tasks easier.


For me this is not interesting because we create a new one, and then, totaling two objects on stage. I believe that the object must come in their original state. In some cases we just add the Bitmap on stage and don't need in a Sprite.


Let me know if anyone agrees.



Link to comment
Share on other sites

You are welcome to simply get the Bitmap directly using the ImageLoader's "bitmap" property, or grab the child of the content Sprite with getChildAt(0).


I received several suggestions for making change to incorporate an immediately-available Sprite and I can see why it could be very convenient. Not only does it ensure that the "content" property is always the same type (Sprite) (previously it could be a Bitmap or a Loader based on whether or not script access was denied) but it also greatly simplifies things like defining an area into which the image should be placed and moving the object around on the stage even before its remote content has fully loaded. Again, you don't have to put the Sprite into your display list if you prefer not to. It's a convenience that I suspect a LOT of people will appreciate.


I'd love to hear everyone else's thoughts too, though. Do you like the change? Hate it? Indifferent?


EDIT: ".bitmap" was changed to ".rawContent" to make it consistent for ImageLoaders and SWFLoaders

Link to comment
Share on other sites

Well, if we have two options, and if the sprite is not created automatically, we have no problem.

I was just using "loader.content" did not know you had implemented ".bitmap". This way is perfect.

Thank you!

Link to comment
Share on other sites

I guess I was wrong, the sprite is created anyway?

In this case I am still in favor of the original object, or just create depending on our access to property.

Link to comment
Share on other sites

Help me understand why you're opposed to even creating a Sprite instance internally. There are several benefits to doing so, but I'm not seeing any significant down sides.

Link to comment
Share on other sites

I think it is not necessary to create another object, I believe the programmer should create it if necessary.

Despite a sprite not raise hardly anything to memory, it bothers me knowing that I have created an object that I am not using.

Maybe I'm too strict.

Link to comment
Share on other sites

Yeah, it's all about balance and figuring out the cost/benefit ratios. You shouldn't have to worry about the inner workings of the class - it keeps things in order internally. Creating a Sprite doesn't suddenly cause garbage collection problems (in fact, in this case it helps with gc) and it doesn't cause a big memory spike. It delivers a bunch of benefits with almost no cost. Even if you don't see the value right now, I'd be willing to bet that within the next 6 months, you'll work on a project and realize the value of having it structured this way :)

Link to comment
Share on other sites

You are right my friend.

And not to lose the habit... great work, and thanks for share. ;)

Link to comment
Share on other sites

By the way, I just posted an update that changes ".bitmap" to ".rawContent" to make it consistent between ImageLoaders and SWFLoaders. Sorry about any inconvenience that caused.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.