Search the Community
Showing results for 'resize' in content posted in GSAP.
Found 2,324 results
-
Animation quirks and inconsistencies across browsers
Jonathan replied to Raymond Chow's topic in GSAP
Ok.. i only see that jitter behavior after it animates in Firefox when scaling text .. But here is an example of animating the font-size instead of using scale to resize the text due to that Firefox jitter bug. This is so we can just isolate the mouseenter and mouseleave tweens, to test with: Hover over Mr Lizard in Firefox: http://codepen.io/jonathan/pen/ryKGj/ The text scale is being animated with scale The text font-size is being animated with fontSize Even adding properties like perspective, transform-style, backface-visibility only help a little.. But.. if you add rotationZ : 0.01 and z : 0.001 to the hover tweens, then the shift/jitter thing doesn't happen after the animation completes, Open the following link in Firefox: No jitter but now blurry like webkit bug: http://codepen.io/jonathan/pen/Hlwds/ You see the text scale becomes blurry when hovered, like it does in webkit bug .. So by solving the shift/jitter thing, now blurry text is our new enemy.. so i guess we can hope Firefox fixes that bug, since it has been around since 2011 ... So either way we cant win -
Hi and welcome to the GreenSock forums. Is really hard to say what could be the issue without some code at least. The ideal situation is seeing a reduced sample that includes only the code that's causing the problem: http://forums.greensock.com/topic/9002-read-this-first-how-to-create-a-codepen-demo/ For what I can see in your site is that there are very large images in it, this can cause quite some nightmares some times. Inspecting a bit in your site there are paintings for big elements (1780 x 764, 1780 x 510, etc.) that take from 60 milliseconds to 130 milliseconds, that's way too much if you consider that the refresh rate of a browser is 16.6 milliseconds (60fps). To see this better resize the browser window to half the screen, probably you'll see a much better performance. With that said my guess is that this has nothing to do with GSAP. Mainly the browser is getting overwhelmed in this one. One option could be add force3D:true in the tween's config object in the tweens that involve the large images: TweenLite.to(element, time, {vars, force3D:true}); That will pass that particular instance to a GPU layer and could improve performance, but don't use this too much because it'd end up hurting performance instead of improving it. Use it just for those elements, I believe there are two large images in the page you linked. See what happens with that and let us know. Rodrigo.
-
Hello grimey, and Welcome to the GreenSock Forums! I don't have access to your big 2300px map image.. but .. 1) Regarding your first sentence... Here is an codepen example of using GSAP Draggable to drag an image within a div. This is much smaller version of that concept, since codepen would not let me upload a large image to test with. But it will get you started: Example #1 (simple smaller concept): http://codepen.io/jonathan/pen/tFokL/ To get the div to fit with the browser window 100%, here is another example. Note that I'm making that small image fill the div which is filling the browser window: Example #2 (fit with browser window 100%): http://codepen.io/jonathan/pen/bKAqn/ I commented in the CSS to see how to make the image resize with the browser. So try forking the examples, and add your big 2300px map image to test with. 2) Regarding your second sentence... I'm kind of confused what your asking for.. Are you talking about adding markers and lables? Also feel free to checkout the Draggable Docs Hope this helps?
-
Timeline doesn't adjust for percent when it comes to width/height
jamiejefferson replied to HeroicNate's topic in GSAP
Ok my first guess was that you were mixing units, and yep! you are tweening width between '0px' and '50%'. Try '0%' and '50%' and GSAP will stick to % for the entire tween. If you mix units, it's going to convert the % width to px and tween as px. The px values will be recorded at the start of the tween and are only re-recorded if you invalidate() the tween. If you really need to mix units, you should be able to get them working if you invalidate() the tweens on window resize. Next time if you can't make a reduced example, just put the whole thing in codepen/jsfiddle etc and link the files to your server. The chances of someone both discovering your issue, and working out a fix for it, is much higher if we don't have to setup the example ourselves... I appreciate that at least you considered it though! http://codepen.io/jamiejefferson/ (if you want this removed just let me know) By the way, that's a pretty neat effect you're working on there! -
Hi, What you could do is loop through the elements and store their original offset positions in the element and when the condition isn't met tween to that particular values: var boxes = $(".box"); $.each(boxes, function(i,e) { var position = $(e).offset; e.originalLeft = position.left - 8; e.originalTop = position.top - 8; }); // then in the Draggabke instance onDragEnd:function(e) { var snapMade = false, targetEl = this.target; for(var i=0; i<targets.length;i++) { if(this.hitTest(targets[i], overlapThreshold)) { var p = $(targets[i]).position(); TweenLite.to(e.target,0.1, {left:p.left, top:p.top, x:0, y:0}); snapMade = true; } } if(!snapMade) { TweenLite.to(e.target,0.1, {x:10, y:10, top:targetEl.originalTop, left:targetEl.originalLeft}); } } That should return them to their original position when the page was rendered for the first time. Be aware though that if for any reason the positions change, window resize, other tweens, etc., you'll have to run the loop again after those events. Also, in case you're wondering why there's a - 8 in the positions values, that has to do with the fact that in the codepen the <body> element has it's natural 8px margin. But that's in modern browsers, other browsers have different margins (if I recall correctly IE9 and some versions of Opera) so for the best crossbrowser behaviour I'd recommend you using margin:0; for the body element in the CSS. In that case remove the - 8 in those expressions. Rodrigo.
-
Haha that's not "unexpected"; that demo was never intended to accommodate for any rotation or transforms etc. If you want rotation and resize, it's in your court if you want to try and get it working. If you have a Shockingly/Business Green membership then Jack's new point tool would likely be helpful in this endeavour.
-
I agree with Jack, until its only about dragging and resizing, it works fine. But if you try to rotate the element and then try to resize, you will experience some unexpected behaviour, here: http://codepen.io/praneybehl/pen/JtAac?editors=111
-
My bad, I forgot the key-up part of the code: $(document).keyup(function(r) { if (r.keyCode == 38) { scrollTween.pause(); } if (r.keyCode == 40) { scrollTween.pause(); } }); That should take care of the tween being paused. As for the animation being smooth, unfortunately there's not much it can be done. Scrolling can be quite a handful for the browser some times because it doesn't have to take care of what is on the screen now, but what is coming. To see what I mean, resize the browser window so it's approximately half of the screen size, you'll notice that the animation is quite smoother, this has everything to do with rendering and not GSAP. One choice could be use force3D:true in the tween config object: var scrollTween = TweenLite.to($("div"), 20, {scrollTo:{y:'max'}, force3D:true, paused:true}); This will basically pass the element to a layer in the GPU, which could improve performance. Another possibility is that perhaps scrolling doesn't support sub-pixel rendering, which basically means that every time the value for scrollTop is calculated the browser rounds it to a whole number. If so you could translate that particular element in the Y axis and use force3D as well, that will ensure sub-pixel rendering: var elementHeight = $("div").outerHeight() - $(window).height(), scrollTween = TweenLite.to($("div"), 20, {y:elementHeight, force3D:true,paused:true}); The rest of the code, that is the key event handlers, remains the same, another flexibility of GSAP. Also you can find all the free tools of the library in CDNJS, which can make it faster to access: http://cdnjs.com/libraries/gsap Rodrigo.
-
Hi Carl, Thanks for taking the time to help on this. This tween is one tween in a pretty huge timeline that contains other timelines. I'm controlling the playhead using the scroll position of the window and the user can go forwards and backwards at any time. I should have been clearer with this I'm sorry. I don't want to force the user to go all the way back to the start of the main timeline if they adjust the window size. Your demo works fine for restarting the tween, but if I change the restart to reverse (I can't fork your Codepen for some reason) , it obviously breaks because the values have been cleared and invalidated. The likelihood of the user scrubbing back over the timeline to the point where this tween occurs after adjusting the size of the window is minimal, but this is the sort of thing my client is likely to do! So I guess what I really need to do it somehow adjust the existing tween values upon window resize so the tween will look correct when it is scrubbed over again instead of jumping to the old stored values.
-
I'd still suggest you try it. Assuming this timeline would only be re-generated on a de-bounced window.resize() I don't see it being a problem. Unless you have hundreds of tweens I don't think it would add any noticeable overhead. If you only want to update a single tween in a timeline, you can create a reference to that tween: var someTween = TweenLite.fom(blah, 1, {}) add that tween to a timeline: tl.add(someTween) when necessary invalidate the tween someTween.invalidate() http://codepen.io/GreenSock/pen/4dd801bb6538c22b1035887d46856c2a/
-
Thanks for all the help on this. I did implement Rodrigo's suggestion. Be sure to resize the browser to the div size(will fix that later - limitation of the viewport plugin used). On codepen: http://codepen.io/cmmize1/pen/gltzw Sample site: http://www.pradev.com/one-page/sample.html On an ipad (both chrome and safari) the screen flickers at the end of the drag, I'm thinking it is when I destroy the draggable instances and recreate the new one. Any ideas on how to stop that? In your opinion, is this the best way to go about this for a one page multi-directional web site?
-
Hi Abhilash, In that scenario the best recommendation is work with percentages and as Jack pointed either create all the tweens again (if necessary), you can achieve this by creating the tweens/timelines in a function, and call the function that creates the tweens/timlines on resize. You might find this post useful: http://forums.greensock.com/topic/9063-best-approach-for-conditionally-disabling-tweens/ Also is always better to see a reduced live sample, please also check this post: http://forums.greensock.com/topic/9002-read-this-first-how-to-create-a-codepen-demo/ Rodrigo.
-
If your not using jQuery in your site than window.resize should work just fine. Glad you got it figured out!
-
Hi Jonathan, thanks for your help. I shortened the code in order to work in CodePen. http://codepen.io/anon/pen/ABvqm What i'm trying to fix is the rollOver state, you will notice that the green panel should always cover the text with a 25px padding. this comes from this variable bgHeight = $(element).find(".text-box").height()+25; The issue is that when you resize the window, you will notice that the green panel will not cover the text properly, but if you refresh the preview area, it will be fine. Let me know if that makes sense. Cheers, Thales
-
Hi, yeah i think what i need is the resize event, the only thing i'm not sure about is the code that would refresh the variables. for example: bgHeight = $(element).find(".text-box").height()+25; The height of the element changes as the window resizes but the variable remains the same. Cheers, Thales
-
When doing a className based tween, the unit of properties is not respected. Here is an example: http://jsfiddle.net/KxfUN/ I would expect the tween to see that the start value is a percentage for the top property, and the end value is a percentage, and adhere to that unit. However if you inspect the element during the tween, it uses pixels. If I'm able to explicitly use percentages in other CSS tweens (ie TweenMax.to(element, duration, { css: { top: "50%" } }) ) then it should behave the same in className based tweens, no? I think this is valuable in the rise of responsive websites where viewports are of varying sizes, and percentages allow developers to create "fluid animations" (using percents or other dynamic units) that work everywhere. If I resize a browser amidst a paused tween thats done these conversions, it's likely going to produce undesirable results.
-
ScrollTo bug in 1.8.2 in Safari 6.0.2 & Mountain Lion
jamiejefferson replied to sibhod's topic in GSAP
Ah, here's the scroll throttling code Carl mentioned. You could also utilise the excellent throttle-debounce plugin by Ben Alman for this. Debounce: Wait until scrolling is complete to run code: var scrollTimeout; $(window).on('scroll', onscroll); function onscroll(e) { clearTimeout(scrollTimeout); scrollTimeout = setTimeout(scrollcomplete, 200); } function scrollcomplete() { // code to run after scrolling here } Throttle: Run code throughout scrolling, but at a lower rate than the scroll events: var scrollTimeout, scrollactive = false; $(window).on('scroll', onscroll); function onscroll(e) { if (!scrollactive) { scrollupdate(); // throttle the next scrollupdate scrollactive = true; clearTimeout(scrollTimeout); scrollTimeout = setTimeout(function() { scrollactive = false; }, 200); } } function scrollupdate() { // code to run during scrolling here } Actually, it looks like you are doing something similar for your resize events already... -
I see what you mean, and we'll look into this for a potential future release. We're working very hard on a few other features right now, and given the fact that the px tweens visually look the same (unless you resize the browser mid-tween, as you mentioned), it's somewhat of an edge case that we can't prioritize quite yet. It's not as easy to implement as one might think Thanks for bringing this up, though.
-
Hi guys, So I have a "default" class for an element that places it offscreen and ready to be animated in. I remove the "default" class in the tween which works just fine. <style> .myelement { left: 0px; } .myelement.default { left: -200px } </style> TweenLite.to(".myelement",speed, { className: "-=default" }); Now, I have some scaling logic in place that is fired on resize. When resized, the "left" property is updated which now needs to overwrite the ".myelement" left value contained in the element's .myelement class. TweenLite.to(".myelement",speed, { className: "-=default", left: "-300px" }); My guess is that the ".myelement" left value is overwriting the passed "left" parameter. Any suggestions on optimizing this is greatly appreciated. - Mike D
-
Thanks you Carl for providing the GSAP way! This actually brought a few things into perspective for me. A couple things though. First, I'm not sure the easing is being used. I forked your fiddle and added the EasePack plugin (since I realized it was missing to begin with) but that didn't seem to help. New fiddle here. Second, I'm also currently looking at a way to draw a path without using the clear() method on the paper with the goal being that I'd be able to draw one shape via a path, then convert that into a standard shape after the animation completes (which I'm not sure how I'd address just yet, but figure that's a common task in Raphael), then "chain" the next path animation, continuing until all animations have been drawn to the screen and converted to shapes that could then be scaled on window resize. Here's a fiddle of where I am with that if you feel like another challenge. My main question though is in regard to the easing, as I understand the other aspects may be out of the scope of what you guys want to support via the forum. Thanks again to you and all the guys here at Greensock!
-
Its ok.. I faked a click by calling startDrag after a screen resize this seems to sort everything out. So all good.
-
Once you have declared a draggable object is there away to delete it again? The reason I ask is that I have page that works really well controlling multiple tweens as you drag the container. The problem comes if the browser is resized and I get all sorts of odd results. if you hit refresh then it works fine. So my thinking is the easiest way to get around this would be to redelclare everything after a resize. I've done this for the timeline animations but i can't seem to find a way to get rid of the "draggable" once it has been set. There is a "disable" but what I would like to do is completely remove it.
-
Yep, disable() is all you need. Is that not working for you or something? Also, could you provide a very simple codpen or jsfiddle that demonstrates the odd behavior after a window resize?
-
i want to ask an additonal question to this topic please! i write a small interface script: http://tvim.de/scrollto/scrollto.html it works brillant! Thanks to Greensock Team! But when i resize the window, it has problems centering my divs. without greensock there are no position problems. i think its because greensock uses "px" values to calculate scrollTo destinations. but can i have them with percentage? i tried it but it does not work: TweenLite.to(scrollsrc, 1.5, {scrollTo:{y:"30%", x:"30%"}, ease:Power4.easeInOut});
