SVG:Notification Mechanisms

The current SVG content model directly maps to the SVG IDL, with heavyweight objects backing the attributes, meaning for a single attribute we currently have two objects (the animated type and the baseval) and possibly a third for the animVal.

Given our current observer hookup mechanism, we would always need to allocate this animVal (since the frames hook to the result of GetAnimVal) unless we introduce some proxy that would switch between sending events from the baseVal and a newly allocated animVal resulting from animation of an attribute.

Robert O'Callahan has suggested that we might want to simplify our storage of attributes to save in code size, time, and space. Since direct use of the SVGAnimated* types in the IDL is rare, these could be tear-offs created on demand. Code like this:

 // DOM property: x ,  #IMPLIED attrib: x
 {
   nsCOMPtr<nsISVGLength> length;
   rv = NS_NewSVGLength(getter_AddRefs(length),
                        0.0f);
   NS_ENSURE_SUCCESS(rv,rv);
   rv = NS_NewSVGAnimatedLength(getter_AddRefs(mX), length);
   NS_ENSURE_SUCCESS(rv,rv);
   rv = AddMappedSVGValue(nsSVGAtoms::x, mX);
   NS_ENSURE_SUCCESS(rv,rv);
 }

Would change to:

 // DOM property: x ,  #IMPLIED attrib: x
 mX.Init(this, nsSVGAtoms::x);

Notification of events to frames will need adjustment for this.

roc: I would change the SVG observer system to observe content objects instead of individual properties; those objects are already XPCOM objects and adding a new interface and making them weakly referenceable is not such a big deal. Then Will/DidModifySVGObservable would pass an extra parameter indicating what property was modified. Furthermore, every SVG frame (or at least the primary frame for each SVG element) should automatically be treated as an observer of its content element without needing to say so explicitly. In that case most SVG elements won't need any explicit observers (right?), and we could perhaps move the observer lists to an external hashtable.

bz: Note that the setup roc suggests is very similar to the existing AttributeChanged notifications, which are unconditionally delivered to frames.

It probably makes sense for nsSVGLength etc to support animation values implicitly. Maybe we could get to something like this. Or am I dreaming? :-)

class nsSVGLength
{
public:
     void SetContext(context);

     nsresult SetBaseValueString(const nsAString& aValue);
     void GetBaseValueString(nsAString& aValue);
     float GetBaseValue(nsSVGCoordCtx* aCtx);
     float GetBaseValue(nsSVGElement* aContent)
     { return GetBaseValue(aContent->GetCtxByType(mCtxType)); }

     float GetAnimValue(nsSVGCoordCtx* aCtx);
     float GetAnimValue(nsSVGElement* aContent)
     { return GetAnimValue(aContent->GetCtxByType(mCtxType)); }

     nsIDOMSVGLength* ToDOMBaseVal(nsSVGElement* aContent)
     { return new DOMBaseVal(this, aContent); }
     nsIDOMSVGLength* ToDOMAnimatedVal(nsSVGElement* aContent)
     { return new DOMAnimatedVal(this, aContent); }
     nsIDOMSVGAnimatedLength* ToDOMAnimatedLength(nsSVGElement* aContent)
     { return new DOMAnimatedLength(this, aContent); }

     struct {
         float mAnimatedValue;
         float mBaseValue;
         PRUint16 mAnimatedValueSpecifiedUnitType;
     } AnimatedValues;
     union {
         AnimatedValues* mAnimatedValues;
         float mBaseValueInSpecifiedUnits;
     } data;
     PRUint16 mBaseValue;
     PRUint8 mCtxType; // X, Y or Unspecified
     PRPackedBool mIsAnimated:1;

protected:
     float BaseValInSpecifiedUnits()
     { return mIsAnimated ? data.mAnimatedValues->mBaseValue : data.mBaseValue; }
     float AnimatedValInSpecifiedUnits()
     { return mIsAnimated ? data.mAnimatedValues->mAnimatedValue : data.mBaseValue; }

     // TODO various stuff

     struct DOMBaseVal : public nsIDOMSVGLength
     {
         DOMLength(nsSVGValue* aVal, nsSVGElement* aContent)
           : val(aVal), content(aContent) {}
         
         nsSVGValue* val; // kept alive because it belongs to content
         nsCOMPtr<nsSVGElement> content;

         nsresult GetUnitType(PRUint16* aResult)
         { *aResult = val->mBaseValueSpecifiedUnitType; return NS_OK; }
         nsresult GetValue(float* aResult)
         { *aResult = val->GetBaseValue(content); return NS_OK; }

         // TODO etc
     };

     // TODO DOMAnimateVal, DOMAnimatedLength
};

I also want to have a close look at the attribute mapping system. It seems to me that we don't need mapping information on every object, it should just be per-object-type.

Do we want to do this step now or continue with the existing scheme?

roc: I think this should be done before implementing animation.

Some historical discussion regarding svg animation:

http://groups-beta.google.com/group/netscape.public.mozilla.svg/browse_thread/thread/e9b98baa2df08082/3d2c37ff3def6907?q=animation&rnum=2

roc: I like those ideas. But I think we need a global animation controller that is not SVG specific. I'll put something about that here: [[SVGDev::AnimationController]].'