Cache color

[Vitroze]

Just a color cache

[StyledStrike]

Caching colors for the effects is fine, but doing that for the debug overlays is unecessary given that debugging is not always active in normal gameplay, and it just ends up using more memory. It shouldn't be done on ENT:EnableCrosshair too, since each vehicle might modify the color instance that was placed on self.crosshair.

Also there's no need to cache colors on functions that were using separate RGBA components (surface.SetDrawColor( R, G, B, A )) when those colors are never modifiable anyways, using a color instance is slower in that case too.

I've seen some related pull requests that you've opened, and I'd like you to consider this before doing them:

How likely is a section of code to be running constantly?

You don't have to cache stuff for things that run on very specific circumstances, like the Repair SWEP HUD, the Engine Stream editor, or game.SinglePlayer in #304.

Lastly, try to avoid using existing color constants that GLua added, since I have seen some addons modifying it accidentally. (In other words, do not use color_white)

[Vitroze]

Caching colors for the effects is fine, but doing that for the debug overlays is unecessary given that debugging is not always active in normal gameplay, and it just ends up using more memory. It shouldn't be done on ENT:EnableCrosshair too, since each vehicle might modify the color instance that was placed on self.crosshair.

I actually checked the GLide source code and I didn't see the crosshair that changes color unless you're talking about other addons.

Also there's no need to cache colors on functions that were using separate RGBA components (surface.SetDrawColor( R, G, B, A )) when those colors are never modifiable anyways, using a color instance is slower in that case too.

If you say so, I think the principle of color caching must also have been in SetDrawColor

You don't have to cache stuff for things that run on very specific circumstances, like the Repair SWEP HUD, the Engine Stream editor, or game.SinglePlayer in #304.

I agree about the game.SinglePlayer setting; however, I think it's necessary for the repair HUD and Engine Stream. Indeed, although the Engine Stream menu is rarely used by average users, it's at least necessary for other users to cache these colors, which consume a lot of resources in Paint or Think. Regarding the repair HUD in Roleplay servers that use Glide, users don't always hide the SWEP Repair. I think it's important to cache it, and this will prevent the unnecessary re-creation of colors.

Regarding debug colors, why not create a global table that is only activated if the server has a developer convar greater than 0? This would solve the problem for most servers and still create a cache for those that need debug mode.

Lastly, try to avoid using existing color constants that GLua added, since I have seen some addons modifying it accidentally. (In other words, do not use color_white)

Yes, some addons use and modify the color_white property. However, I see very few that do. Is it really necessary to base our decision on the minority of addons that do and remove color_white altogether? If you think so, we can revisit the previous idea of ​​grouping all the most frequently used colors (i.e., those that appear multiple times) into a global table, such as color_white, color_red, etc.

[StyledStrike]

unless you're talking about other addons.

Yes I am.

it's at least necessary for other users to cache these colors, which consume a lot of resources in Paint or Think.

Using the separate RGBA components like I said would've been better for performance, and completely negate the need to cache the colors in the first place. Some of those surface.SetDrawColor calls already did that before you made this pull request.

Glide.DrawWeaponCrosshair can even accept a nil color parameter, since it will use a cached white color instead.

...although the Engine Stream menu is rarely used by average users, it's at least necessary for other users to cache these colors, which consume a lot of resources in Paint or Think

The Engine Stream editor never did that, until you replaced the surface.SetDrawColor( R,G,B,A ) calls with Color instances. Same thing for the aircraft STALL text, the Sound Browser's footer panel, the category panels from the Misc. Sounds tool, and the Homing Launcher's lock-on area.

why not create a global table that is only activated if the server has a developer convar greater than 0

That's a unecessary complication for, once again, something that is never activated in regular circumstances.