invalidateStyle needs invalidation itself

I’m working on the next version of our component set and implementing all of it’s styles. I was trying to figure out how components knew to redraw themselves when one of their styles change since they don’t seem to subscribe to any style events.

After digging for a while I found mx.styles.CSSSetStyle and notifyStyleChangeInChildren(). Seems a little odd, it loops through every movie clip in the entire application and calls invalidate style based on some criteria. Regardless of criteria, it recursively loops through every movie clip in the entire application.

This is all based on a single setStyle call. So, I did a little testing. I put a trace statement in notifyStyleChangeInChildren, added a bunch of components to the stage, and a few frames later I made some setStyle calls. With one setStyle call, notifyStyleChangeInChildren was called 316 times and with four calls 1260 times.

That’s a lot of calls, and a few seconds of frozen movie. So seems like we need a new setStyle method that invalidates the call to notifyStyleChangeInChildren, which itself just invalidates styles. Or better yet, how about adding in an event interface so we don’t loop through every movie clip but instead only those that use the style we changed.

Oh, and btw, it only loops through clips from _level0 onward. I guess if you load things into _level1 or higher, they don’t update based on style changes.

::sigh::

5 thoughts on “invalidateStyle needs invalidation itself

  1. With a lot of excuse to everybody…
    All we get from FMX2004 is a bunch of waste code and abstruse ‘hooks’ within predefined classes. Where is the documentation? After paying so much money for brand new Flash we have to dig for life-saving crumbs and waste the time on it. However, thanx a lot for info ::sigh::

  2. It’s things like this that really get frustrating.

    I really wish Macromedia would spend time to think things through from start to finish rather than rush products out the door. I think they’d see their stocks improve too if they could actually MEET the expections they give their customers. We don’t want a ton of new features, we want features that WORK without having to wait for the “next version” to come along to fix it.

    The only reason they can get away with this level of quality is because there aren’t any competitors for Flash. That needs to change.. and soon.

    Check out this post from Nigel on FlashCoders that just enforces the “rush out the door” mentality and seemingly lack of planning.

    http://chattyfig.figleaf.com/ezmlm/ezmlm-cgi/1/88333

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>