[Gnash-dev] Re: --once parameter regression

[Kristian Erikson]

Hi guys

So in relation to this. And thanks for your answer strk. I've found
the source of the problem now. It appears, it's due to the fact our
file only has one frame in the movie_root. In that frame our new
MovieClip instance is launched, in which our animation plays. However,
when Gnash is launched with the "--once" flag, the logic for quitting
is currently the following:

on line 981 in gui.cpp (in the 0.8.6 release):

        if ( ! loops() )
        {
                size_t curframe = m->get_current_frame(); // can be 0 on 
malformed SWF
                const gnash::MovieClip& si = m->getRootMovie();
                if (curframe + 1 >= si.get_frame_count())
                {
                        quit();
                }
        }

This means our animation instance is never played as when curframe = 0
or 1 (of movie_root), and si.get_frame_count (the movie_root's total
frames) = 1, Gnash simply quits, before even playing the first (and
only) frame in the movie_root is played, as this is currently.

I realize we could just change our SWF and put the MovieClip animation
into the movie_root, and everything would work fine. However, I feel
the best solution would be for Gnash to ensure that the movie_root,
and instances inside it, has finished playing before quitting. So it's
not just based on the movie_root, but also the instances inside it.

I've been working not making a patch that does this, but I can't
figure out how to access the MovieClip instances inside the
movie_root. Ideally I want to see what their current_frame and
frame_count is so I could maybe turn it into a loop that checks
instances in the tree? and ensures this is true for all MovieClip
instances.

However I want to make sure that you guys agree with this as well. Do
you agree that MovieClip instances of the movie_root should be checked
if they're finished before exiting when the "--once" flag is enabled?

And, if you agree. Can you please give some pointers as to how I can
access those MovieClip instances? and do I access their frames
information?
I've been searching through the Gnash source code for a while now for
this, and I just can't find it anywhere... Im sorry if Im asking a
silly question.

Thanks in advance
Kristian

2009/12/30 Sandro Santilli <address@hidden>:
> This may be related to a bug filed for fscommand:quit being ignored when found
> in first frame. The bug there is that the GTK main loop isn't started
> at time of gtk_quit
> call. The assertion you get from GTK seems to be the same...
> Just an hint to help  you looking at it.
>
> --strk;
>
> On Sun, Dec 27, 2009 at 10:59 PM, Kristian Erikson <address@hidden> wrote:
>> Heya guys
>>
>> Here at eyemagnet we've noticed that the “--once” or “-1” parameter
>> doesn't always work as intended any more with some files. In the 0.8.4
>> release of Gnash the parameter could be given to files that it will
>> not play now, given the same parameter, so it must be a regression. So
>> basically with the 0.8.6 release we noticed that some files fail to
>> play when given the “--once” parameter. To give an example please try
>> playing the the following files:
>>
>>    gnash http://fliiby.com/fliiby-logo3d.swf
>>    gnash --once http://fliiby.com/fliiby-logo3d.swf
>>
>> As you can see the first one plays back fine, but when given the
>> “--once” flag the window never opens and the GTK-critical error is
>> returned:
>>    (gtk-gnash:5225): Gtk-CRITICAL **: gtk_main_quit: assertion
>> `main_loops != NULL' failed
>>
>> I've been doing some testing and have found that not all files are
>> affected by this issue, and it appears to be spread across different
>> SWF versions as well. Trying to fix the problem and come up with a
>> patch I first tried figuring out how the “–once” parameter is parsed.
>> I found (please correct me if I'm wrong), that it basically ends up in
>> “gui/gui.h” as “ bool loops() const { return _loop; }”.
>>
>> I then turned my attention to the initialization of the window in the
>> “gui/gtk” “gui/gui-gtk” related files, hoping the error would be
>> there. However I couldn't find the error there either, and the code
>> structure appeared very similar to the code in the 0.8.4 release, with
>> the only difference being the RunResources structure being passed down
>> to new initializing windows now, as opposed to the bit_depth.
>>
>> I've also tried running Gnash inside a debugger, but that didn't
>> reveal any more information on what causes the error either
>> unfortunately.
>>
>> Seeing as the error does not occur on all files, and it doesn't appear
>> to be at the time of initializing the window, I'm thinking that it
>> must be due to something going wrong when playing the files. Maybe
>> it's in the virtual machine?
>>
>> At this point I'm hoping for a suggestion as to where to look... Does
>> anyone have any ideas as to what might be going wrong? Or maybe a
>> smart suggestion I can use to help find what's causing the error? I'm
>> still hoping to create a patch for this, but I think I need some help
>> to do so at time point.
>>
>> Thanks in advance
>> Kristian
>>
>>
>> _______________________________________________
>> Gnash-dev mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/gnash-dev
>>
>
>
>
> --
>
>  Free GIS & Flash consultant/developer  ()  ASCII Ribbon Campaign
>  http://foo.keybit.net/~strk/services.html  /\  Keep it simple!
>