erikb

This issue I've encountered and worked around is likely addressed somewhere in the last few years. But this thread seemed relevant. This works great for click and drag: http://codepen.io/jedierikb/pen/ORKvJm?editors=0011 This does not: http://codepen.io/jedierikb/pen/XjvBGb?editors=0011 The difference is adding the event listeners for click events _after_ the Draggable.create.

Great explanation -- makes sense. Thanks. You're right -- no need to use ThrowPropsPlugin here at all.

I am using ThrowPropsPlugin on an element, $x. When it is complete, I reset its position via set( $x,{x:0, y:0}) and run the same ThrowPropsPlugin again. It works like a baseball pitching machine. Here it is: http://codepen.io/jedierikb/pen/NRZRgz Now, if I add this one line of code to that example, and also make the element Draggable via Draggable.create($x, {}); Then the baseball pitching machine does not work as expected -- the element $x begins out of bounds. Here it is: http://codepen.io/jedierikb/pen/WGLGRy Advice? Thanks.

Thanks for the explanation. I appreciate the reasons given and agree with you on flexibility first. To recap: for a project I was asked to implement a draggable with some moderate logic (locking axis depending on current state, moving other elements in tandem). It was really easy to do with Draggable. I was pleased. Seeing how great the Draggable looked, I was asked to simulate the draggable when a button was pushed (in addition to the implemented click and drag behavior). My first thought was, 'oh, I bet when I use ThrowPropsPlugin it will engage all of the existing Draggable callbacks' and when it did not I was surprised it did not work. So I came to the forum for guidance. Thanks to Carl I quickly understood how to refactor my code and completed the requirement. Thanks to Blake I have a lot of inspiration and examples. Thanks to greensock I understand the design decisions behind the tools I use. Much appreciated.

Using `onUpdate` will make it work with just a bit of code refactoring. Thank you. However, it would be cool to have ThrowPropsPlugin called on a Draggable execute that Draggable's logic as they're all tools in the same toy box. I was surprised it did not 'just work'.

Thanks Carl, but I am still having trouble. Take a look: http://codepen.io/jedierikb/pen/yaEPZd?editors=0010 When I manually drag the red block, it is locked to the Y axis and also it moves another block via `onDrag` and `onThrowUpdate` callbacks. But when I initiate a simulated drag via ThrowPropsPlugin, the locking and callbacks are ignored. Is there a way for the ThrowPropsPlugin to simulate a drag so that those callbacks are honored? Or how should I re-organize my code (hopefully keeping it DRY) so the throw logic for locking and callbacks works manually (e.g. via the mouse) and automatically( via the ThrowPropsPlugin)?

Thanks Carl and sorry for not providing an example codepen. Your own example is a good one to use an example: http://codepen.io/jedierikb/pen/XjkQbP I've added two buttons to the bottom -- I am trying to understand how I would simulate throwing the rectangles so they hit specific targets on the grid. In this case green would move over to the right 1 and red would move down 1. I am sorry to say I do not understand how I 'create a throwPropsTween on the target of the Draggable', but am encouraged that it sounds like it will be straight forward.

I've a draggable component, replete with rules for onDragStart, onThrowComplete, etc. which, in turn, animate other effects. I am now tasked with implementing a button which will simulate dragging and throwing that component so it hits a snappable target. (as the dragging behavior was not discoverable) Is there a straightforward way to do this? A phantomDragAndThrower?

Having just read through https://bugs.chromium.org/p/chromium/issues/detail?id=596382, I wanted to say thank you to team GreenSock for investigating this issue. Appreciated.

Perhaps obvious, but two more considerations: (1) if your svg is appended to any parent node with a subpixel position, it may cascade down to your svg causing blurriness. (2) In chrome (at least) rotating with the default transformOrigin can lead to blurriness. Setting transformOrigin to '0 0' and translating clears it up for me.

And the scrollToPlugin has onAutoKill https://greensock.com/docs/#/HTML5/GSAP/Plugins/ScrollToPlugin/

I've a rather simple animation -- just bouncing some svg balls around. I am wondering though if there is a performance win for one approach over another. Is it better to have one svg element with many circles inside tweening OR better to have multiple svg elements and just move the svg element around? Both are easy enough to build -- but before I do, I thought to come here to solicit some feedback. Thanks!

Thanks slopps!

I am a little confused at the documentation here: https://greensock.com/docs/#/HTML5/GSAP/Utils/Draggable/hitTest/ Is the percent covered for the element being moved or for the element being moved on to? (As the two might be very different sizes, percentage overlap could be very different). Maybe I am misunderstanding something?

Thanks Jack. The code was written with small nephews and nieces crawling over me on a small laptop. I am surprised I was able to demonstrate my issue at all. Regarding #2, I forgot codepen comes loaded with all of the good plugins. Your suggestion is a good one: http://codepen.io/jedierikb/pen/ZOwaNp However, this only updating the lastBlocks when tweening the scroll position -- it does not update when scrolling by hand. I was, however, able to implement a satisfactory solution to my issue: http://codepen.io/jedierikb/pen/oLVvJj On 101 I check if a paused tween to move the scrollTop was created. Iff that paused tween has been created and we've not passed its duration, I then set the elapsed time on that paused tween which (thankfully!) updates the tween immediately, changing the scrollTop position. On 100 I check if the scrollTop has changed (either from a tween or user scrolling) and do my book keeping on what is in view. On 0, the pulsating tween updates those elements now in view. Slightly awkward, yes. But it 'works for me' Much thanks!

Thanks guys, this is helpful. Here is an example of the situation I have (should have done this first... sorry): http://codepen.io/jedierikb/pen/KrJvgr When I scroll by hand up and down the proxied color animation is always in bounds. But when the tween takes over the scrolling (by pressing the link), the proxied animation is a step behind. How are you suggesting I force the animation which updates the scroll to update before the ticker callback on priority 100? Much thanks!

Alternatively, if I were to move all of my book keeping to priority zero, how would I know scrollTo had changed the scrollTop before I applied my other tween to update only the elements in view? Is there a priority for tweens? Thanks for helping me to figure this out.

I am listening for events on the ticker at different priorities. Tween events fire at priority 0, so I arrange my other ticker callbacks around that. One of the events I listen for at priority 100 (before tweens). This event checks if a scrollable area has had an update to its scrollTop which could happen from a scrollwheel between ticks. Based on the new scrollTop value, I do some book keeping on what elements are now in view. Then, when we get to priority zero and the tweens update, proxy objects ensure only those elements in view get updated with nifty css effects. Last night, I tried using the scrollTo plugin and got odd behavior from my current setup. Since the scrollTo update is presumably firing on priority zero, it is happening after I am normally doing my book keeping for changes to scrollTop on priority 100. Therefore the wrong elements are getting updated when there are large scrolls movements. I plan to work around this by keeping track of the time passed and on priority 101 using a variant on the technique described here: http://greensock.com/forums/topic/12534-pick-value-between-2-css-values-using-gsap/ to update the scrollTop value. This is feels funky. It would be super if I could set the priority of a tween to fire at a different priority (in this case, I would fire the scrollTo plugin at priority 101).

Nevermind -- found this thread here: http://greensock.com/forums/topic/10464-how-to-access-plugins-and-utils-through-npm-module/?hl=browserify#entry54847 By providing a somewhat lengthy path to my bower_components import {ScrollToPlugin} from '../../../../bower_components/gsap/src/uncompressed/plugins/ScrollToPlugin'; I was able to get it to work. Much thanks greensockians!

Loading in greensock via bower, and using gulp (and browserifyBower) to browserify gsap. Successfully add gsap to a library file and load gsap this way. However, when tacking on ScrollTo plugin to the list of files to browserifyBower, it is being added to the generated library file, but it is not accessible during runtime. Blake, I see your message and have read it now many times through, but am not sure how to act on what you are suggesting. I also know there were some improvements in the last release related to bundling -- any pointers? Thanks.

Does this community have any insight regarding the rate at which content in a scrollable element moves when selecting text and dragging beyond the element's container? For example, if you select some text from the top here with your mouse: http://www.gutenberg.org/cache/epub/52512/pg52512.txt and then drag down out of the browser window, your selection is automagically extended while you scroll. Moves a little slower when you are closer to the boundaries. Seems to reach a maximum velocity at a certain distance. I want to know what the rules for that scroll rate are. I want to re-create that functionality with greensock. Tech note: the reason I want to re-create it and not use that functionality 'out-of-the-box' from the browser is that for other technical reasons I need to return false / preventDefault on the mouseDown event. This prevents the auto-scrolling.

Is there an example of using throw props on a vanilla object? I plan to update the movement of my nodes myself when there are updates on the tween. Any advice / warnings / suggestions? Thanks!

My fix (for now... would like to be on the main release branch again) https://github.com/jedierikb/GreenSock-JS/commit/f10a7828f7f8c62271d8909e649e7988e4cd501b

Ran into an issue this evening. If adding a callback to the ticker during a different ticker callback, there is a chance the ticker will miss some of the callbacks already scheduled. In the console output for the pen, notice that a callback with priority 1 is skipped on frame 30. I have implemented a hotfix of my own for this issue by modifying the TweenMax source for dispatchEvent. I clone the list with a list.slice(0); before iterating through it. New listeners will not be added until the next tick, but that is understandable behavior. Thanks for looking into this.

I can alleviate the problem as so http://codepen.io/jedierikb/pen/xOGbyr by passing in a bound callback. Is that the recommended solution? Using bound functions seems to be redundant as we also pass in the scope through your ticker.addEventListener...