Fri 09 Oct 2009 09:02:47 AM UTC, comment #23:
Tried unwatch, doesn't have any effect. I'm closing this bug.
|
Sun 13 Jul 2008 03:52:31 AM UTC, comment #22:
I'v no any plan to improve the "textField intsance variables" shortly. So I don't assign it to myself. Anyone else that interests this item may take over it.
|
Fri 04 Apr 2008 07:31:12 PM UTC, comment #21:
would be at least worth making sure using .unwatch on a registered
textfield variable doesn't break the link.... would be fun if it does... (hardly, but just to be sure)
|
Fri 04 Apr 2008 07:18:33 PM UTC, comment #20:
Isn't this a similar pattern?
onAnyChange = function()
{
trace("something happened, args: "+arguments);
};
o = {};
o.watch("l", onAnyChange, o);
o.l = 1; // will call onAnyChange("l",undefined,1,o)
o.l = 2; // will call onAnyChange("l",1,2,o)
delete o.l;
o.l = 3; // will call onAnyChange("l",undefined,3,o);
o.l = undefined; // will call onAnyChange("l",undefined,undefined,o);
|
Fri 04 Apr 2008 04:19:46 PM UTC, comment #19:
Udo wrote:
> SS> One thing to look at could be the Object.watch/unwatch taht might
> SS> be useful for cases like this. Not sure they work like that but
> SS> it could be a separate table of "hooks" in the PropertyList
> SS> which would be invoked anytime a variable with a given name
> SS> would be added/deleted/modified/changed_of_flags.
> SS> Such "hook-by-name" support could be also useful for the debugger
> SS> (watchpoint).
>
> Properties can be functions, right? So a textfield might need to
> update itself in every frame without any other accessing that
> property. Does the current design deal with this?
Sorry I didn't understand the question.
Properties do can be functions (getter-setters).
Using them would have been one cleanup option, but wouldn't
deal with the 'delete' case..
> What about simply adding an additional step after
> movie_root::advance() where each text field explicitely checks it's
> associated variable and calls set_invalidated() if necessary?
Could be a way.
in that case the textfields would register with movie_root instead that with target timeliens..
|
Fri 04 Apr 2008 03:19:29 PM UTC, comment #18:
strk: yes, I understand Gnash works with the TextFieldMap.
>I confirm I've seens invalidation problems in the pp, so this
>might be another case in which we have to choose between
>bug emulation and doing a better thing.
>I wouldn't insist too much in compatibility here.
If it is just a compatibility problem, I wouldn't care much either. But as you see in the testcase:
Define a textField instance and associate it with variable_a;
delete variable_a;
trace(variable_a); // pp give undefined, while gnash doesn't.
Obviously, the first result is more intuitive, isn't it?
Bug or compatibility issue, it's debatable here. Especially if we forget about the invalidation problem here(eg. no invalidated bounds checking), the solution of this bug is cleaner than the current one in concept. (the TextFieldMap has GC or memory overhead I guess, thinking about dead TextField instances.)
|
Thu 03 Apr 2008 03:50:35 PM UTC, comment #17:
zou: impossible is a big word, as we're currently doing it.
Udo: you remember correctly, we hook on the registered variable
exactly to call set_invalidated.
The problem is we're loosing on ActionScript compatibility
in that the reference player allows actionscript code
to mess with that link, like deleting the associated variable
or protecting from modification and so on.
I confirm I've seens invalidation problems in the pp, so this
might be another case in which we have to choose between
bug emulation and doing a better thing.
I wouldn't insist too much in compatibility here.
|
Thu 03 Apr 2008 02:38:10 PM UTC, comment #16:
>So we want to the invalidating happen at the displaying stage.
Nope, that's not possible.
Here is a breakdown what happens between frames:
1) all characters are advanced and some of them call set_invalidated()
2) the GUI calls add_invalidated_bounds() to get the invalidated ranges.
3) the GUI configures the renderer to clip outside these invalidated bounds, ie. ignore any pixels outside these areas [depends on rendering backend, applies for AGG at least]
4) for all invalidated characters the display() method is called, clearing the m_invalidated flags.
5) loop to (1) after inter-frame delay
You see, calling set_invalidated() after #2 will lead to unexpected results. At the time you want to invalidate the text box you have already configured the renderer and even if you draw on the stage the renderer might just do nothing because the pixels are out of the clipping area.
With other words: There is no way to invalidate a character while it is being displayed because it depends on the invalidation if the character should be displayed (=rendered, matches display() ) at all.
I thought text fields register the referenced variable to get notified about changes!?
If not and if such a link is not desired I see only one solution left: add an intermediary step after advance() that recursively checks all characters if they need to invalidate. But I wonder if that's the right way to go as the correct solution probably depends on proprietary player's behavior (like text fields linked to properties returning random data - AFAIK the PP has some invalidation problems with these).
|
Thu 03 Apr 2008 01:38:42 PM UTC, comment #15:
I think your two phrase model should work in theroy. But the main purpose of the invalidated bounds checking is to speedup the player. Then let's consider the case about the textField variable.
> Do I understand the problem correctly that the textField
> instance doesn't know when the variable changes and thus can't
> call set_invalidated()?
The textField instance can know if it checks. The problem is when we call set_invalidated() for this instance. For example:
(1)there is a textField instance named as inst_a.
(2)there is another variable named as var_b. inst_a and var_b are associated by a DefineTextField tag. And the following should be satisfied(expected behaviour): inst_a.text == var_b.toString().
(3) inst_a and var_b might be at two completely different timelines, thus have different parents.
In the current mode, we should invalidate inst_a whenever var_b is changed or var_b.toString is redefined or var_b.toString is affacted by some global variables. But it's almost impossible. So we don't know when to invalidate inst_a at the stage of executing AS .
But conceptually, we do know whether we should update inst_a.text or not. Before the time to rendering inst_a, we can check if inst_a.text == var_b.toString() first. if yes, then we redraw inst_a; if not, then do nothing. So we want to the invalidating happen at the displaying stage. (break the current mode??)
|
Thu 03 Apr 2008 12:29:17 PM UTC, comment #14:
> Note that if I understdood the inv bounds thing correctly
> we wouldn't even get a call to add_invalidated_bounds to hook
> the lookup on IF our parent doesn't know we've been invalidated.
Correct. set_invalidated() makes sure that all parents get the m_child_invalidated flag set. Only characters with m_invalidated get added to the invalidated bounds ranges and only characters with m_invalidated or m_child_invalidated recursively query all their childs.
This is a two phase model:
During the first phase the movie is advanced causing actions to be executed and set_invalidated() to be called where necessary. Calls to add_invalidated_bounds() during this phase are only used to calculate the current position of visible elements in the sprite in question ("force" flag is set) - i.e. invalidation does not matter at this point. It's just used as a more precise replacement to getBounds().
In the second phase all XXXX_invalidated flags are ready and add_invalidated_bounds() is used to collect all characters that want to redraw themselves. The flags are cleared after that.
>If we delay resolution of the text at display or bounds
>computation bound we will fail to call set_invalidated in time.
>There is likely a way to do this, but needs some thinking.
set_invalidated must be used during advance(), however before the GUI calls add_invalidated_bounds().
Do I understand the problem correctly that the textField instance doesn't know when the variable changes and thus can't call set_invalidated()?
|
Thu 03 Apr 2008 09:09:07 AM UTC, comment #13:
Just so we have them.
I did give the normal props a try in the past and
still have the in-progress work around, so I tought
I'd attach it.
It's full replacement for sprite_instance.{cpp,h}
and edit_text_character.{cpp,h}. Not sure they'd work
after all this time.. Unfortunately only the edit_text_character.cpp file contains an RCSId to produce
a patch against, all others where from unknown revision
(but all in 2007...)
(file #15394, file #15395, file #15396, file #15397)
|
Thu 03 Apr 2008 08:02:33 AM UTC, comment #12:
Agree, they are normal properties, and lookup happens
when needed.
Now, the problem with that is invalidated bounds computation.
If we delay resolution of the text at display or bounds
computation bound we will fail to call set_invalidated in time.
There is likely a way to do this, but needs some thinking.
A good start could be adding invalidated bounds testing
in the existing test runner, to make sure the textfield
will be redrawn when value of the associated variable changes.
Note that if I understdood the inv bounds thing correctly
we wouldn't even get a call to add_invalidated_bounds to hook
the lookup on IF our parent doesn't know we've been invalidated.
|
Thu 03 Apr 2008 06:01:18 AM UTC, comment #11:
See new tests in DefineEditTextVariableNameTest.c.
Seems textField variables are handled differently as normal variables in Gnash code, that makes me uncomfortable:) They are just normal variables/properties in my brain model.
|
Wed 02 Apr 2008 01:08:47 PM UTC, comment #10:
You may close this one or two days later if nothing new found. I'd like to try few more tests, but just because the model in Gnash is a little different against the model in my brain.
|
Wed 02 Apr 2008 10:32:09 AM UTC, comment #9:
Seen your commit, no failures.
Will you keep trying to break it ? (I'd be happy if you do:)
|
Wed 02 Apr 2008 12:59:36 AM UTC, comment #8:
I am working on the tests, will commit it recently.
|
Tue 01 Apr 2008 06:51:57 PM UTC, comment #7:
second attempt works both for MotionDiagram and simpleguess,
committed.
|
Tue 01 Apr 2008 06:44:44 PM UTC, comment #6:
eh, my patch broke swf4/simpleguess.swf
working on another approach..
|
Tue 01 Apr 2008 06:36:57 PM UTC, comment #5:
Committed a patch avoiding the registration if there's
no text defined. Some automated test would be nice to have.
|
Sun 30 Mar 2008 03:35:49 AM UTC, comment #4:
> It seems 'acceleration' is the VariableName of a textfield,
> so the problem might be in handlign of that..
I believe so. 'acceleration' is defined within the 79th tag(DefineTextField). The problem was registering and initializing this variable. There should be a subtle difference between gnash and pp when handling textfield variable.
According to the tests here: If a textfield variable is defined without initial text provided(i.e. flag 'hasText' = 0), this variable shouldn't be registered to the timeline where the textfiled instance is placed immediately. The registration might be triggered at later steps.
The above is the expected behaviour. I guess Gnash always registers the textfield variable whenever it's defined, haven't review the detailed code at the moment though.
|
Sat 29 Mar 2008 04:44:21 PM UTC, comment #3:
A good small swf file. I am interested in tracking this. So assign it to myself at the moment.
|
Tue 04 Mar 2008 11:41:30 AM UTC, comment #2:
It seems 'acceleration' is the VariableName of a textfield,
so the problem might be in handlign of that..
|
Tue 04 Mar 2008 11:33:48 AM UTC, comment #1:
Math.round('') correctly returns NaN.
The argument (empty string) is
evaluated from a 'level' variable which is fetched from _level0,
but I can't find any setter.
Indeed, running gnash with -P "FlashVars=acceleration=0"
fixes it.
|
Tue 04 Mar 2008 11:12:43 AM UTC, original submission:
http://faraday.physics.utoronto.ca/PVB/Harrison/Flash/ClassMechanics/MotionDiagram/MotionDiagram.swf
version: SWF6
md5: dfce34df33f0172b18cc7fd9c59c274c
car acceleration evaluates to NaN.
Relevant action log shows it's the result
of a Math.round(''):
PC:597 - EX: ActionPushData (dict_lookup[17])
0) type=dict8 (17), value=[string:round]
After execution: PC 597, next PC 602, stack follows
Stack: "[gnash::movie_instance(_level0):0x817e768]" | "[string:acceleration]" | "[string:]" | "[number:1]" | "[object(gnash::math_as_object):0x81b8d18]" | "[st
ring:round]"
Local registers:
Local variables: arguments==[object(gnash::as_array_object):0x81f6ff8], super==[null], this==[gnash::sprite_instance(_level0.instance1):0x81db680]
PC:602 - EX: ActionCallMethod
method name: [string:round]
method object/func: [object(gnash::math_as_object):0x81b8d18]
method nargs: 1
After execution: PC 602, next PC 603, stack follows
Stack: "[gnash::movie_instance(_level0):0x817e768]" | "[string:acceleration]" | "[number:nan]"
|