Improve GSDevTool Trial for us

[Mumm-Ra]

Please improve GSDevTool Trial Visual UI for us.

I discovered yesterday GSDevTool Trial, sorry I couldn't test this tool yet but I know it is very nice!

a) add a visual UI with a horizontal ruler with timeline tick texts;

b) add a new unit "frame" at the timeline besides "current Time" and "total duration Time" to debug the animations based on "frames".

 

It is necessary to  necessary to pass a parameter {currentframe: true} at the GSDevTools constructor.

GSDevTools.create({
  animation: walk, // tween or timeline
  timeScale: 0.5, // numerical value
  paused: false, // true, false
  loop: true, // true, false
  //globalSync: true, // true, false
  inTime: 0.333, // time or label ---> add a new unit "frame"?
  outTime: 0.5, // time or label  ---> add a new unit "frame"?
  css: { width: "90%", bottom: 30 },
  //container: '#id', // any selector text (class works too)
  //visibility: 'auto', // hidden, visible
  //minimal: false, // true, false
  currentframe: true // displays current frame
  // dopesheetFPS: 30 // TODO
});

Please don't call the police, be patient with me, I put my dirty hands and touch this original DSDevTool trial lib and
I puts some horrible JS lines to add a new unit "frame" at the timelime:  "current frame" and "total frames".

		B = V.create(x, {
		type : "x",
		cursor : "ew-resize",
		allowNativeTouchScrolling : !1,
		allowEventDefault : !0,
		onPress : Uo(x, .5, !0),
		onDrag : function onDrag() {
			var e = g + u * this.x;
			e < 0 ? e = 0 : e > v._dur && (e = v._dur),
			f || v.time(e),
			y.style.width = Math.min(D - S, Math.max(0, e / v._dur * 100 - S)) + "%",
			w.innerHTML = (r.currentframe) ? Math.round((v._time / v._dur) * 30) : e.toFixed(2),
			_.innerHTML = (r.currentframe) ? Math.round((v._dur) * 30) : v._dur.toFixed(2)
		},...

		Y = function updateProgress(e) {
			if (!B.isPressed || !0 === e) {
				var t,
				o = d || -1 !== i._repeat ? 100 * v.progress() || 0 : (i.totalTime() / 1) / (i.duration() * 100 / 1),
				n = i._repeat && i._rDelay && i.totalTime() % (i.duration() + i._rDelay) > i.duration();
				100 < o && (o = 100),
				D <= o ? !d || v.paused() || B.isDragging ? (o === D && -1 !== i._repeat || (o = D, v.progress(o / 100)), !C && (D < 100 || 1 === i.totalProgress() || -1 === i._repeat) && I()) : n || (o = S, (t = v._targets && v._targets[0]) === i && t.seek(s + (l - s) * S / 100), 0 < i._repeat && !S && 100 === D ? 1 === i.totalProgress() && v.totalProgress(0, !0).resume() : v.progress(o / 100, !0).resume()) : o < S && (o = S, v.progress(o / 100, !0)),
				o === T && !0 !== e || (y.style.left = S + "%", y.style.width = Math.max(0, o - S) + "%", x.style.left = o + "%",
					w.innerHTML = (r.currentframe) ? Math.round((v._time / v._dur) * 30) : v._time.toFixed(2),
					_.innerHTML = (r.currentframe) ? Math.round((v._dur) * 30) : v._dur.toFixed(2),
					h && (x.style.transform = "translate(-50%,0)", x._gsap.x = "0px", x._gsap.xPercent = -50, h = !1), T = o),
				v.paused() !== C && O()
			}
		},

Uh! very ugly code! ....and  I think I also have to TODO include an custom {dopesheetFPS: 30},  and customize the arguments "inTime" and "outTime"  to work with new unit "frame".

[GreenSock]

Hi @Mumm-Ra. Thanks for the suggestion - are you basically asking us to make GSDevTools "frame-based" instead of "time-based"? 

 

The problem with that is GSAP is inherently resolution-independent in terms of timing, and that's a GOOD thing. In the old days, a lot of systems were frame-based, so for example you might make an animation that linearly travels 600px between frame 10 and frame 70, so 10px per frame. Seems fine initially, but what if you run that animation at a timeScale of 0.25 (quarter-speed)? Since that animation was frame-based, it's resolution-dependent, meaning it only has 60 frames worth of motion and if we now slow the playback speed, it looks a lot more jerky. 

 

GSAP, on the other hand, is resolution-independent in terms of time, so if you timeScale(0.25), it'll adjust perfectly and the motion will be totally smooth. It's not locked to moving 10px per frame like in the frames-based animation. And remember that even if requestAnimationFrame() is supposed to run 60 times per second, sometimes it doesn't. The system could be temporarily bogged down. In a frames-based system, that would mean the entire animation would take longer to finish. For example, if the system was working really hard and the frame rate dropped to 30fps, that 60-frame animation would take 2 full seconds to complete! But with GSAP, it'd still honor the 1-second duration; it'd just move a longer distance on each frame. 

 

All that to say that I do not believe it would be a good idea to make GSDevTools frame-based. It may give the false impression that GSAP works that way. A developer might intricately build out an animation such that a particular element starts moving in exactly frame 62...but then in the real-world browser on a system that's much less powerful, it may actually end up firing on tick 41 instead because the frame rate dropped. 

 

Why do you need things to be frame-based? What is difficult for you about using time (seconds)? 

[Mumm-Ra]

A created a video showing an example using GSAP with both "time-based" and "frame-based."

 

Improve GSDDevTool visual UI

[Cassie]

Heya,

 

As Jack mentioned, there are no 'frames' in GSAP animations. So it would be pretty confusing to have a GUI that works that way. 

 

Maybe a stepped ease is what you're after?
https://gsap.com/docs/v3/Eases/SteppedEase/

 

You can step through the progress of a timeline too, if you're using a stepped ease you could step though that number of times?

See the Pen NWJQvdy?editors=1011 by GreenSock (@GreenSock) on CodePen

 

Good luck with your learning.