incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <>
Subject Re: invalidateParentSizeAndDisplayList justification
Date Sun, 25 Mar 2012 21:26:07 GMT
On Sunday, March 25, 2012, Left Right <> wrote:
> Hello, I've been taking a more close look at the code and I found that
> particular function is used a lot (almost any other method or property
> has to do with graphical display of a component uses it to notify the
> parent of the component about the change).
> Here's the function itself:
>    protected function invalidateParentSizeAndDisplayList():void
>    {
>        if (!includeInLayout)
>            return;
>        var p:IInvalidating = parent as IInvalidating;
>        if (!p)
>            return;
>        p.invalidateSize();
>        p.invalidateDisplayList();
>    }
> Now, I can understand what purpose this function serves, but I also think
> that it is a bad thing to do, and here is why:
> - every child (especially bad if there are many) will cause parent's
> revalidation - this is a situation prone to infinite validation loops,
> properties dealt with have rounding errors and parent will cause
> repetitious validation of the children, while children will, in return
> cause repetitious validation of the parent.
> - it, out of nowhere assumes that the parent, in order to by notified
> the change must be an IInvalidating - what gives? This is one of the
> hated features of Flex framework. It never cares about any other code and
> always assumes it lives alone in the application, so, no other container
> having Flex framework display objects will not even have a chance to
> interact with them in a proper way, because, obviously, it is not an may
> not be an IInvalidating...
> Normal approach to this problem would be to use events, or, if you are
> concerned about performance, then use callbacks. I.e. a parent of this
> component would give a callback function to this component, which this
> component would call once it updates itself. This is an idiomatic way for
> other Flash classes to communicate: the child has registered a mouse click
> - it sends an event to the parent, and the parent then may decide to
> it, the child doesn't invokes parent's methods handling the click.
> Now, this particular approach resulted in all kinds of ugly solutions like
> this one for example:
>    public function set depth(value:Number):void
>    {
>        if (value == _depth)
>            return;
>        _depth = value;
>        if (parent != null && "invalidateLayering" in parent &&
> parent["invalidateLayering"] is Function)
>            parent["invalidateLayering"]();
>    }
> Magic strings... not using interfaces... not handling potentially unsafe
> reflection calls (what if invalidateLayering needs more arguments?) The
> code like this earns bad name to the framework... but it's not an easy
> patch. the invalidateParentSizeAndDisplayList is used something like 100
> times in SpriteVisualElement alone, so, fixing this will require a
> decision. Since this function is protected, there's a chance people used
> / have it overridden, so if it gets removed, it will cause compatibility
> issues...
> So, I'm asking what to do / is there any prepared course of action
> regarding such situations, will we be able, and in what time, to deprecate
> old features?
> Best
> Oleg

I don't see any possible way of doing this level of refactoring with any
level of confidence without first getting our hands on the Mustella tests.
Without those tests there's no way to know that thing aren't being broken
throughout the framework.

Personally, I'm in favor of these kinds of changes. But, like you pointed
out, that method is protected and removing it can break lots of apps. I
think this kind of change would have to happen in a major release of the
framework where breakage is expected.

I don't want to discourage anyone from working on this stuff, I'm just
bringing up things I think we should consider during these kinds of
proposed changes.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message