jdhadwin
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Posts posted by jdhadwin
-
-
Hi guys, I created a logo animation for an upcoming site launch. It uses an SVG mask to punch out a white SVG and reveals the video beneath, all while GSAP animates the reveal. In a second or two, the white fades, the logo reforms and drops to what will become a nav bar. Works great in Chrome, Safari, & Firefox, EXCEPT not in Brave & Opera browsers only respect certain parts of the animation.
Here's what's really weird. Half the animation goes pretty much as expected. Yet even the first half IS animating on the targeted elements, as demonstrated when I look at the inspector. Though the elements are animating, the onscreen result is nada. See if you also have this phenomenon in Opera & Brave whilst not at all in Safari, Chrome, or Firefox.
If any of the collective wisdom has already advised on this matter, thanks in advance for the tip-off. All help is appreciated.
-
Temporary work around is that I can do
gsap.set('#forecast', {touchAction:'manipulation'}); //target the SVG element and force manipulationimmediately after instantiating any Draggable, but if I'm reading the Draggable code right, (line1767):
QuoteSome browsers like Internet Explorer will fire a pointercancel event when the user attempts to drag when touchAction is "manipulate" because it's perceived as a pan. If the element has scrollable content in only one direction, we should use pan-x or pan-y accordingly so that the pointercancel doesn't prevent dragging.ie is ancient history (at least in my mind) but I don't know whether this still matters.
@GreenSock If you were me, how would you handle this. I just need my SVG to be able to be pinched/spread zoomed in/out, and for scrolling to be able to continue if the SVG becomes full screen... which wasn't possible when Draggable was assigning pan-y or pan-x. -
@GreenSock The use of the Draggable plugin is appending the
style="touch-action: pan-y;"attribute to the svg itself. This is what is causing the behavior I don't want, but I don't know how to fix it.
Any ideas how I can prevent the Draggable from adding this to the entire SVG?
-
I put this pen together for touch devices, but code pen on touch is a bit tough. Explanation in the pen.
I can't figure out why touch doesn't work as expected over the SVG. I'd appreciate any enlightenment. Especially when the SVG takes up the whole screen, it even becomes impossible to scroll away from the SVG. Gestures are also broken over the SVG for reasons I can't understand, especially since the scale is reporting during the event. Below the chart/SVG you'll see a readout of the gesturechange event's event.scale property, as it changes. So it's working, but it's not working.If you pinch/spread over anything except the SVG it works. Maybe I'm just burned out, but I can't launch my web app over this, because people can get stuck on the SVG if it lands at full screen in landscape orientation.
Ideas?
See the Pen MWRbQwd?editors=1010 by jdhadwin (@jdhadwin) on CodePen
-
Out of curiousity, when you guys have a full screen svg, how do you guys prefer to handle scrolling, since full screen svg doesn't respond to page scrolling... pure js or gsap?
-
22 minutes ago, GreenSock said:
Have you tested my theory? Check the getBBox() of the element on both and see if they match (testing and live servers). Do so at the very start (not when you click).
I only tested it on update... and it was the same there... but I haven't checked it before. I will check
-
12 minutes ago, jdhadwin said:
Nevertheless, it would solve my problem, except that I have other elements animating and scaling around the group, and they are changing sizes and locations, affecting the bBox size of the g. So center won't cut it in my case. I need to explicitly anchor to the original origin of the g. Trying to think of a way without a zillion calculations onUpdate.
Well, it just occurred to me, that I could ensure that transformOrigin: 'center center' stayed at the x:0 y:0 of my g element if I simply put a giant invisible circle at x:0 y:0. Then the inner elements can be animated like crazy and yet the bBox would remain the same size. Technically the problem is solved, as now both servers render the same outcome, however, mind is still boggled on the difference in the first place.
-
@GreenSock the difference between the two servers is blowing my mind.
Nevertheless, it would solve my problem, except that I have other elements animating and scaling around the group, and they are changing sizes and locations, affecting the bBox size of the g. So center won't cut it in my case. I need to explicitly anchor to the original origin of the g. Trying to think of a way without a zillion calculations onUpdate. -
@GreenSock In the HTML of the codepen above, the circle #billInput is at cx:0 and cy:0, that's the big orange circle, and it's placed inside the g element #subject. The circle's center is at the origin of the g element.
It is my understanding that
gsap.to(subject, {duration:1, scale:.05});would by default transform around the center of the circle #billInput, because the center of the circle is the x:0 y:0 origin of the group being transformed. In my video above, on the testing server, the gsap scale tween of the g #subject would scale around the center of the circle, yet on the live-server it scaled around the center of the g #subject bounding box.
That is why I found that adding transformOrigin: 'center center' unified the destination at which the tween landed. Without transformOrigin, it arrived at different destinations based on whether it was served by the testing server or online. Which is the correct behavior, default bBox center or default group origin at x:0 y:0?
-
Thanks. As you predicted smoothOrigin:false changes nothing.
However, BIG CLUE... setting transformOrigin to anything DOES unify the two sources so that the animation ends at the same point.
Thoughts?At this time I cannot reproduce the problem with code pen, but working on it, however, I did get it to land in the wrong spot with this pen... just problem is, it also acts the same on my testing server as it does on codepen. Other confusion here is that shouldn't the origin of the g element arrive at the destination without transformOrigin set to center center?
In the demo below, the set() and to() methods both send the orange circle to the same coordinates, HOWEVER, once the group is shrunk, it interprets the coordinates differently. Click the blue dot to execute the set() method or the orange dot to do the to() method. You'll get different results with the set() method based on whether the orange dot group is shrunk.
-
Same code, verified same (xy) coordinates being passed to gsap.to(), good results on testing server, and very different animation on real-world server. How is it possible?
Here's a video to check out the phenomenon: -
From a motion graphics background, I find viewBox to be nothing less than a 2 axis 2D camera. The difficulty for me has been that I find myself wanting to create a camera object that controls it. Here's v1.0.
What would you guys do to make it more effectual? I noticed one problem. Inserts like '-=1' will not work as desired without changing the Camera.gsapify() method.
-
This community is AWESOME
-
2
-
-
Thank you @Cassie. I'm a MGFX video guru (After Effects) first and a coder (distant) last-place. I had something of an existential crisis momentarily upon realizing that viewBox acts as a virtual camera while viewPort acts as the wildly varying screen size... not because it isn't awesome, THAT it truly is... however, it was because I wrote my entire app as though that did not exist. The chart and whatever plots are generated to match viewPort size. I really appreciate you and @Rodrigo causing me to realize that the <g> is inheriting from ` M ` command in the path, and that was where I was really unaware. Perhaps I was most confused because developing locally on Laravel's Herd, everything worked as I expected. But immediately on uploading to a remote server, the offset appeared. I don't have time to figure out what the heck that was all about, but I'm thanking God for you two.
My mild existential crisis bore some fruit too. I added viewBox which eliminated the need for window resize calculations and re-drawing, then added a few lines to my code that created a virtual camera so that I can focus a user's attention somewhere more like a videographer would than a coder would.I found an SVG editor on github and used it to re-craft my svg so that the origin 0,0 is at the fingertip. Learned a lot about SVG today! What do you guys use to create SVG's? I was hoping Illustrator would be more useful to me... but seems to not be the right tool. Thoughts?
Up and running as expected now, thanks to your help.
Cheers!-
2
-
-
Inspiring
-
Hi everyone, newish to GSAP, first-time posting.
I have a complex webapp I've built and have stripped it down in order to demonstrate this problem in a sensible way. The problem is explained by the pen... please forgive all the excess code. Please help me determine how to resolve the unintentional XY offset. As you can see, the applyPointer() method gets the coordinates of an SVG circle, then applies them to an SVG group (containing a few paths that form a pointer). Even though the code resolves to the correct coordinates, gsap.set() produces a matrix that does not match the coordinates. I cannot see anywhere the difference/offset could be coming from. Help!
Thank you all in advance for any insights.
~JD
Brave & Opera Browser Animations
in GSAP
Posted
Wow, based on what you said, I tried it while resizing the window and you could see the animation running, but as soon as you stop the resize the problem remains. Without <g> tags I'm kind of screwed, so I was looking forward to solving my problem using your work-around. However I found that even after commenting out all the scale-based tweens, leaving behind only one thing:
In the following codepen, I removed everything except this set() command, and the problem remains in Brave and Opera. So the Chromium problem is now bigger than it used to be. It isn't just scale:0 as it was in 2022. Now it is also the transform property. Aware it's not gsap.
See the Pen eYoeKpz by jdhadwin (@jdhadwin) on CodePen