Performance: Adjusting UIGradient transparency vs. TweenSize/TweenPosition for GUI elements

Help and Feedback Scripting Support
#1

This is more or less a question about efficiency - let’s say I have an XP bar that grows as I gain XP. I’ve already implemented TweenSize as it is supported, however I find that there are sometimes failures to tween, and certain easing styles are not able to tween for certain tweens I am using. After UIGradient came out, I was wondering if using the transparency feature would be a simpler option, using TweenService or lerp/iterated loop to adjust the “time” position of the transparency parameter.

It’s not really for implementation, but I thought it would be good to know if anyone has tried using transparency for this case or similar cases, and if it runs smoothly. I’m not looking for raw performance stats, I just want to know if the implementation itself is considerably slower or not. I may migrate to such a system just to avoid TweenSize calls failing in the future.

Thanks for any feedback!

1 Like
#2

Tween methods for GuiObjects shouldn’t fail unless there is some type error or you’re just misusing them. Please give us examples of how it fails. Also, I think using UIGradient would just make your use case (an XP bar) harder than it has to be. I much prefer using TweenService methods with TweenInfo configurations and the table of properties–this allows me more programmatic control over the client’s interface and GuiObject animations.

e.g.

local TweenService = game:GetService("TweenService")
local XP = --[[path to GuiObject]]

-- GuiObject:TweenSize Implementation:
XP:TweenSize(UDim2.new(0.5, 0, 0.5, 0),
	Enum.EasingDirection.Out, 
	Enum.EasingStyle.Quint,
	.5,
	true,
	callback
)

-- TweenService:Create() and TweenSize:Play() Implementation:
local Config = TweenInfo.new(
    .4, -- Tween time
    Enum.EasingStyle.Quint, -- Easing style
    Enum.EasingDirection.Out, -- Easing direction
    0, -- Repeat count
    false, -- Does it reverse when complete
    0 -- Delay time before tween
)

TweenServiceService:Create( -- creates the animation
    XP, -- instance to tween
    Config, -- TweenInfo configuration
    { -- properties to tween:
        Size = UDim2.new(.5, 0, 1, 0),
        BackgroundColor3 = Color3.fromRGB(0, 200, 83)
    }
):Play() -- plays the animation

-- [[Sidenote: With TweenService, you can also store the created animations returned from the Create method and play them inside some other programmatic logic.]]
2 Likes
#3

Whenever I use the “cubic” easing style, the Gui does not tween - it just teleports to the origin, and then to the desired location. This is the main issue I’ve been having since for me, Quartic and Quad are outside the Tween style that I wanted. But that’s the nitpicking part.

Why do you think this is the case? As I said, the XP bar is just growing/shrinking - it’s only a one-dimensional change, which the transparency property of UIGradients can control. I don’t need fancy animations for it or more “programmatic” control. All I have to do is change one number.

And thank you for providing an example, but I’m not looking for example code - I want to know if there is significance in latency or otherwise, and if the implementation itself is. It’s not something I plan to use now, I was just curious since UIGradients are quite new and they have a lot of capability as we learn to use them.

Thanks for taking the time to put a good reply together though. Much appreciated!

#4

That’s very odd, can I see a video? Cubic should follow an acceleration curve like this:

Screen Shot 2020-03-06 at 1.26.23 PM

I guess this would be an okay choice, and I highly doubt there is anything more than a negligible performance impact for using UIGradient contraint properties on something like a client-facing XP bar instead of using a Tween.

3 Likes
#5

Here is a sample code I used. I’m using a brand-new frame on a brand-new baseplate.

local frame = script.Parent

while true do
	frame:TweenPosition(
		UDim2.new(0.3, 0, 0.3, 0),
		Enum.EasingDirection.In,
		Enum.EasingStyle.Cubic,
		0.5,
		false	
	)
	wait(1)
	frame:TweenPosition(
		UDim2.new(0.1, 0, 0.1, 0),
		Enum.EasingDirection.In,
		Enum.EasingStyle.Cubic,
		0.5,
		false	
	)
	wait(1)
end

Here is the result: https://streamable.com/ltyh7

The frame is flashing back and forth, teleporting to the origin, then it’s destination. If I switch the easing style to linear, it does not do this (and in fact, none of the other easing styles produce this weird behaviour). https://streamable.com/geto4 is the link to the linear video.

Sorry for ignoring this post for a while, I wasn’t sure how to upload a video since I’ve never done it before, and I’ve been quite busy. Someone just helped me figure out how to do it in recent post.

#6

Personally I just manually interpolate my values but the performance cost is really insignifiant if you only update it for the amount of time that is necessary (not updating or checking every frame if it does not need to be updated). Most of the time I spawn threads to take care of the change and they execute until the change has been fully made, even if it has been changed during the process.

You might think that spawning threads when I need to initiate interpolation is not performant but trust me, it is better than lerping or checking 50+ values every frame for no reason at all.

The two ways to do this is to have a dictionary containing tween information and take care of that data asap in a thread, or spawning threads whenever you need to start an interpolation. You will have a lot more control of what goes on visually, but get too overboard and it may start causing problems.
Hint: You don’t need 10 calculus equations to interpolate a health bar.

2 Likes