About Last Update 01-06-2010

[flashdev]

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.

 

Thanks.

[GreenSock]

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

[flashdev]

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!

[flashdev]

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.

[GreenSock]

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.

[flashdev]

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.

[GreenSock]

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

[flashdev]

You are right my friend.

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

[GreenSock]

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.