Having written the current animation system myself, I have some
familiarity with the problem. I think there may be some confusion about
the role of ActionScript. If you are not creating a full blown SMIL
engine in ActionScript, then you will be creating something in the
general mold of what I already have. Whether or not the effects are
serialized as a sequence of ActionScript commands or a sequence of Flash
primitives is relatively unimportant. I suppose it matters to correctly
implement interactive/triggered effects. Also, whether or not a SMIL
engine would work with the raw XML or some preprocessed form of the
SMIL is also a minor detail. I believe the core question to answer is this:
Can the SMIL stream (of whatever form) be altered at runtime (view-time)
without changing the SWF?
If the answer is yes, I would actually recommend working with the raw
XML for easy integration with server-side components. If the answer is
no, then we are really just expanding the scope of what already exists.
The biggest change is that one shape can now have multiple effects,
meaning that we have to change the code to process a stream of effects
(each applied to a shape) rather than a stream of shapes, each with an
effect. Applying the stream of effects should be quite simple. I must
admit, however, that I don't have a good sense of the scope of
interactive effects. Does an effect with a trigger exist in the main
timeline as well (and is replayed on the trigger), or is it only played
on the trigger? Is the behavior well defined when you trigger two
effects on the same shape? Is the behavior well defined when a shape no
longer has its initial state when an effect is triggered? If a shape
has exited, will triggered effects make it reappear? If effect A is
marked to animate "with previous" and effect B (the previous one) is
marked to animate on a trigger, is A implicitly triggered? etc etc
So I'm certainly all for switching each individual effect implementation
to ActionScript. I see processing the SMIL stream as being the hard
part. If there's an easy way through the OOo API to say, "Give me an
ordered list of the SMIL effects for the main timeline, and then give me
a list of all the triggered effects!" then it shouldn't be too hard. If
there are implicitly triggered effects, that could be a nightmare. I
guess in that case, you would create effect chains. I sense ambiguity
here (can an effect be implicitly repeated by being marked "with
previous" on a looping animation?), and I would probably just ignore
that on a first pass. Unless you guys have better ideas on how to
guarantee correctness.
Augustus
Christian Lippka wrote:
Hi all,
I agree wit Thorsten here. I'm also not thinking about a generic SMIL
engine in Flash. We can do much preprocessing before export. The first
thing would be to flatten the SMIL tree so we only have a list of
effects to work on in flash.
Augustus, I think we are not that far away from our ideas on how to
implement this. I know that looking on SMIL for the first time can seem
very complicated. But the beauty really is the possibility to compose
very complex looking effects by overlaying a small set of simple
effects.
What effects do we have in SMIL?
Transition effects (Blinds, Wipes, etc.)
Transformation effects (Moving, Rotating, Scaling)
Property Effects (Changing fill colors, fonts, e.t.c)
Motion Paths
Thats it! So I think instead of implementing the aprox 114 legacy
effects from OOo 1.x all individually, lets just implement the few
SMIL effects properly.
I agree, if we do not get a action script guru to sign up for this
then having this scripted can be a problem. But as I said, we can
do as much preprocessing during export as we like. So for a first
step the actionscript would not need to be that complex. For file
size it *would* be preferable if much of the action :) is going on
in script but it is not *needed*.
Anyway, I also agree with Thorsten that who ever codes this decides.
The above is only my personal suggestions on the topic.
Regards,
Christian
Thorsten Behrens wrote:
Augustus Saunders <[EMAIL PROTECTED]> writes:
There are 2 sides to this: 1) what is the "most optimal" solution, and
2) what is the "most realistic" solution? The most optimal solution
involves creating an entire SMIL processing engine in ActionScript.
[...]
So we come around to the "realistic" solution. The realistic solution
is to expand upon the work already done and push it as far as it
goes.
Hi Augustus,
well - your effort estimates appear reasonable, but from experience I
can tell that the hacked-up solution will accumulate at least as much
time poured into it over the years, as if we'd do it right up-front.
At any rate, he who codes decides, so this is all my two cents worth
of counsel. But maybe there's something inbetween full-blown,
independently developed SMIL engine, and coincidental effect
generation (yeah, that's what I call it - just import a PPT
presentation, and see that Impress UI really has no clue either, about
what specific effects are in there): the basic SMIL animations are
few, and very simple in nature. Triggering them is event-based (either
time, or other effects start/end, or user interaction). So, whipping
up such a simplified engine should be possible in your two weeks
time frame, and getting that broken-down SMIL is certainly possible
with the existing c++ smil processing.
My rough guess is that we can get to about 90% compatibility without
substantial structural changes.
As I said, I doubt that with arbitrary PPT input. But certainly true
for Impress 2.x generated input.
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
