[x3d-public] CSS st5yle usage for Routes [was: id attribute proposal]

Leonard Daly web3d at realism.com
Mon Mar 21 08:13:48 PDT 2016


On 3/20/2016 9:37 PM, John Carlson wrote:
>
> We can look at draggables with css and classes to get an idea of how 
> to do things every frame.  I am not sure of the IP on that, but I've 
> seen it in jquery and meteor.  I am not sure if it's in a published 
> standard.  I am also not sure about dragging multiple objects...sounds 
> like xerox or apple IP.  Oh well.
>

It's not so much dragging a single object. That is done with an event 
listener on the draggable element and updated every frame. It's not such 
a big deal because the user's attention is focus on the element being 
dragged. Animation of other elements on the page are secondary to that. 
The bigger concern is when there are multiple complex animations running 
that are secondary to something else. That starts generating a lot of 
events.

Leonard Daly




> On Mar 20, 2016 9:27 PM, "Leonard Daly" <web3d at realism.com 
> <mailto:web3d at realism.com>> wrote:
>
>     Additional thoughts - these came as I pressed SEND so it's a
>     separate message.
>
>     In HTML/DOM, events are used to mostly handle extraordinary
>     conditions. It is not a very efficient mechanism to do something
>     every display frame. If the event is a trigger for something else
>     to happen (like a light switch), then it is no big deal. If it is
>     to run animation, then something like my proposed Animate node
>     might be better. This node handles the changes every frame and
>     directly updates the destination from the TimeSensor to the
>     Interpolator. See
>     http://tools.realism.com/specification/x3d-v40/changes-additions-x3d-v33/animate
>     for an initial description.
>
>
>     Leonard Daly
>
>
>
>
>>     Thanks for commenting Leonard, I thought it was going to be left behind in the id/class discussion
>>
>>>     On Mar 20, 2016, at 8:32 PM, Leonard Daly<web3d at realism.com> <mailto:web3d at realism.com>  wrote:
>>>
>>>     could refer to all viewpoint nodes in the main scene. An X3D ROUTE that identified that string as the destination would change all viewpoints. While this is not hard to do (for example jQuery does this), it can cause considerable overhead if you have to check the entire scene graph for matching nodes on every animation step.
>>>
>>     Only check the scene graph when the members of the selection change.
>>
>>>     My initial thought is to not go down this route; however, that just may be my concern on run-time performance and not being creative enough to see all of the good possibilities.
>>     Agreed.  Let’s wait for a good use case. Necessity is the mother of invention.  We can write a route expander in the meantime.
>>
>>     John
>>
>>
>
>
>     -- 
>     *Leonard Daly*
>     X3D Co-Chair
>     Cloud Consultant
>     President, Daly Realism - /Creating the Future/
>
>     _______________________________________________
>     x3d-public mailing list
>     x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>     http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160321/77448294/attachment-0001.html>


More information about the x3d-public mailing list