I like the idea of separating multi-parameter interfaces out into a
mixin. It at least makes the documentation more logical.
---
Another idea that was alluded to in this thread that I think we should
pursue: The concept of a 'batch' interface. This might not be used
directly users, but it would be a way to optimize the animation of
multiple attributes. Two ideas:
LzNode/setMultipleAttributes(plist:Array) where plist is an
alternating list of attribute name and value
This would let the system have a chance to optimize event sending, by
deferring them until all the attributes have been given their new
values.
LzNode/setAttributeAnimator(attribute:String, animator:Animator)
LzNode/animationStep();
This would be a reorganization of the animation substrate. Rather
than individual animators running off the idle clock and triggering
constraint cascades, you assign an Animator object to an attribute (it
contains the parameters of the animation of that attribute), and add a
delegate to the idle queue that runs animationStep on the instance
being animated. animationStep is a similar batch optimization that
uses all the Animators to compute the new values of the animated
attributes of the instance, installs those values, and then sends the
associated events.
Hmmm....
An attribute animator is really just a constraint that is constraining
the attribute value to a function of elapsed time... What can we make
of that?
On 2009-09-25, at 08:48, André Bargull wrote:
Another idea:
Instead of adding all attributes to <view>, which may lead to an
overload, it may be possible to use specialized mixins which add
support for CSS3 features. And only if certain CSS3 features are
necessary, you'd "mix-in" them into your <view>. That way nobody
needs to worry about performance penalties and documentation would
be much easier since there won't be hundreds of attributes for view.
- André
Raju and I had a good discussion, which I'll summarize here. Raju,
please let me know if something is missing.
+ There's no way around adding discreet attributes. This goes to
Rami's point about keeping things simple, logical and consistent.
We need to benchmark with some large apps to see how adding 50+
attributes to lz.view affects performance.
+ We need support for compound attributes. It's a nice option for
developers to use if they want to, and is mostly useful for
procedural code. Instead of calling setAttribute() once for each
value, they could make a single call, e.g. with a generic method
like this.setCompoundAttribute("width: 50; height: 55;..."). Or,
it could be added as custom setters on a case-by-case basis, e.g.
setAttribute("transform", "rotateY(10deg) rotateX(20) rotatez(10)
scaleZ(-5)..."); This could be a good place for optimization when
several attributes need to change at once, and could be related to
the work on enhanced runtime CSS support.
+ We may be able to avoid some of the overhead of adding discreet
setters for 50+ attributes by using a generic setter that knows how
to call sprite APIs by convention. There are a few issues with
this approach: how to constrain to only supported attributes, and
how to provide good documentation.
It could use a whitelist of valid attribute names/types.
Documentation could live on the class properties like it does today.
Raju Bitter wrote:
> I know Max, I'm not sure how to deal with the situation. Compare
this:
> > <view csstransform="-transform-style: preserve-3d; -transform:
> rotateY(10deg)" />
> <view transform-style="preserve-3d" transform="rotateY(10deg) >
rotateX(20) rotatez(10) scaleZ(-5)" />
> <view transform-style="preserve-3d" rotatey="10" rotatex="20" >
rotatez="10" scalez="-5" />
> > I guess the LZX way of doing this would be the 3rd version.
> > - Raju
> > On Sep 25, 2009, at 9:41 AM, Max Carlson wrote:
>
>> Unfortunately, I don't know how else to deal with this if we
want to
>> support animating these attributes.
>>
>> Raju Bitter wrote:
>>> While single attributes are easy to handle, the number of
attributes >>> will drastically increase with all the new CSS
attributes. Think of >>> the 3d transform, and the properties:
>>> http://www.w3.org/TR/css3-3d-transforms/
>>> The following properties exits:
>>> * transform
>>> * transform-origin
>>> * transform-style
>>> * perspective-origin
>>> * backface-visibility
>>> The transform property can contain a selection of the
following >>> functions: matrix(), matrix3d(), translate(),
translate3d(), >>> translateX(), translateY(), translateZ(),
scale(), scale3d, scaleX(), >>> scaleY(), scaleZ(), rotate(),
rotate3d(), rotateX(), rotateY(), >>> rotateZ(), skewX(), skewY
(), skew(), perspective()
>>> Following the attribute approach (one attribute per
function), we >>> would have to add 25 attributes for CSS 3d
Transforms only. That >>> would be attribute overkill, wouldn't
it? Or do we want to add 50-60 >>> attributes to views to
support the new CSS features?
>>> - Raju
>>> On Sep 25, 2009, at 4:29 AM, James Robey wrote:
>>>> Max Carlson wrote:
>>>>> The CSS3 draft allows a shadow to be defined with four
parameters - >>>>> distanceX, distanceY, color and blur
radius. Instead of specifying >>>>> the x and y offset
separately, we thought it made more sense to >>>>> specify a
distance and angle (in degrees).
>>>>>
>>>>> I propose exposing these four properties as separate
view >>>>> attributes (shadowdistance, shadowangle,
shadowcolor and >>>>> shadowblurradius) so they can be animated.
>>>>>
>>>>> An alternate approach is to expose them as a single
compound >>>>> attribute like in CSS3, e.g. 'distance angle
color blurradius'.
>>>>>
>>>>> See http://www.w3.org/TR/css3-background/#the-box-shadow
and >>>>> http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-shadows
for >>>>> more details.
>>>>>
>>>>> What do folks think? I have a change ready to go in,
but Tucker >>>>> reminded me I should solicit feedback first.
Thanks!
>>>> I like the idea of having them as four animate-able
attributes. I >>>> would not like to do string manipulation, of
say, the shadow of a >>>> box moving farther away when it's
"picked up" for a move.
>>>>
>>>> 2 cents
>>>>
>>>> .james
>>
>> -- >> Regards,
>> Max Carlson
>> OpenLaszlo.org
>>
>
-- Regards, Max Carlson OpenLaszlo.org
