the only significant benefit in using a graphic is if you need to see the graphic play while editing on its parent (or some other ancestor's) timeline. otherwise, use a movieclip.
The point of a graphic is to remove the overhead of a MovieClip which can contain multiple frames on the timeline. Graphics also allow shape tweens as they prefer vector graphics.
If you require timeline animation you use a MovieClip, at significant more heft to the objects complexity. Use a graphic when you have no need for any more than 1 frame with as many layers as you like to gain performance.
The Graphic class does some with some unideal limitations. If you want to benefit from using the library rather than building objects with code you can open a library item you wish to be a graphic, change it to a MovieClip, tick off to export for ActionScript and set the "Base Class" as "flash.display.Sprite". Sprites, like Graphics, are not designed for timeline animation and have 1 frame but have MovieClip-like interactivity yet are light-weight.
Thanks for your answers!
I still don't understand why it takes forever to publish the swf if I increase the amout of frames when I use graphics. In my sample there is no tweens or transitions at all, just a static picture as a graphic. I thought the graphic was more "light" than a MovieClip . You can download my sample here.
So, if I want to use different illustrations along the time, like a slide show where you fade in/out the different media (pictures, video clip), I should use MovieClip and not graphics. Is this correct? For static pictures it's no problem for us to use MovieClip but if we add some video clips we want to use graphics since it's easier to control the pause/play function etc for the timeline.
I disagree. Another significant benefit is that it allows you to put objects in the library that you otherwise wouldn't be able to, because it would change their "address" on the stage. For example, if you have a TextField with dynamic text on the main timeline, and you want to share it in a shared library among several xfl's/fla's and make sure the fonts/sizes are the same, you can make it into a Graphic symbol and the instance name will still work (because the Graphic doesn't actually become the "parent" of the TextField--it is still the main timeline!
I just discovered this today in AS2, so I haven't had a chance to experiment in AS3. But plenty of people are still in AS2-land, so this can be helpful to them, even if it doesn't work in AS3. I hope it does, I can think of TONS of places this would be useful!
i can only see headaches because you can't reference the graphic symbol with actionscript. so, as soon as you add more than one of your graphic symbols to a timeline, you have no way to assign text to each.
but that might be more of a developer vs designer perspective.
C'mon now.. AS2? Graphics completely lack the robustness of interactivity and event architecture compared to sprite and are still less efficient (as2). Time to stop hacking as2 to make it faster, give in to AVM2 and love up some AS3.
There are a lot of places where what you want is only one (how many times do you need multiple headerText instances?), but even if not, just because you can't reference the Graphic Symbol, that doesn't mean that you can't reference all instances in them. For example, if your Graphic Instances are available in Frame 1, you can loop through in the Constructor and see what the children are. If not, you can listen for ADDED_TO_STAGE (which, incidentally, is how RobotLegs works.
That's kind of the point. You pretend the Graphic layer isn't there (which, to ActionScipt, it isn't). This removes a layer of complexity that isn't needed (kind of like using a Group to make sure your related objects are center-aligned, without having to add another layer to address them). I suspect this will work with Graphics in AS3 as well, but since I've spent most of the past 3 days maintaining As2 or documenting the new AS3 platform I just wrote, I haven't yet tested it.
I actually think learning AS2 is great discipline (I skipped right from AS1 to AS3, so I didn't have the "pleasure" until the past 6 months or so). Not only does it teach you a lot of history behind AS3, it's so freaking hard compared to AS3 that switching back and forth yeilds amazing speed and productivity gains, kind of like swapping between lifting heavy weights and running.
To answer the original question, I think it's likely that the compiler is creating an image for each frame. Do you get the same delay if you set your graphic to "Single Frame"?
I have used AS2 for about three times as long as AS3 (late adopter, supporting old client projects that lasted too long). It got the job done but as projects get more complex the language really starts to break down in ways AS3 doesn't. I'm talking 30k-50k lines of code on a single app. It's not managable without useful packages. It's also way too tempting to store data everywhere just because you can (c'mon, we all stuck data as a dynamic property of a MovieClip, and it's the wrong thing to do). It's great at first but eventually you spend most of your time trying to "find" things because data/methods/etc are all over the place. It's a mess.
As for the graphic symbol, the lack of a container doesn't at all appeal to me. I'm die-hard burned-in to the mentality that I need to keep all of my objects under my own control, regardless if it's references or containers. The first thing I do is just the opposite as you say, which is put something on the timeline directly with no container. The first thing I do is make a global container and everything goes inside it. A place for everything (in a custom class) and everything in its place (so I know how to expand/debug it).
Thanks Amy for picking up my original question!
And yes, I do get the same delay if I set the graphic to "Single frame". If I set the symbol to a MovieClip - no problem at all.
Yes, AS2 is pretty baffling (once you've worked around the fact that child objects are not available for use in the Constructor if they have theri own constructors, you know you can pretty much tackle everything).
But I toatally disagree with you on this one. If you're doing something for a purely visual reason, then the code doesn't need to know about it.
For example, I have a Class that handles instructions for how to complete a certain kind of question. All it knows is that it has some questions and it has an example page of questions (called exampleClipObj, following our legacy naming convention). This page of questions is at the root of the Instructions to make it easier to inject the questions. However, it has to do all sorts of weird things not related to the logic of displaying its questions, just to facilitate the purely visual task of scaling it up and down to make room for other objects in the instructions (or not, depending on what part of the instructions we're in).
I could potentially use a Graphic to handle the scaling up and down, still allowing the clear path for dependency injection and removing all the weird logic from the page of questions that handle purely visual concerns.
I, personally, believe in using the full capabilities of the tools, and I feel like I haven't lost any control by doing so--because I take the time to understand what the tools are doing and think through the implications of what's happening.
And the beautiful thing is: if it doesn't work out, so what? I've tried something that could potentially save many hours of maintenance, but now I know why I shouldn't do that (if it didn't work, that is). If it does work, I've greatly simplified my logic by putting the responsibility for the visual side squarely where it belongs--the timeline/stage, while keeping control of those things that need to stay in code.
Also, please stop patronizing me. I know who Colin Moock is, and I once helped Alex Harui edit a post he was writing for FlexAuthority. I also know this person, that person, the other person, and blogged for O'Reilly. Big whoop de flip.