Optimised ItemDecorationHandler for the default case

[HenryLoenwind]

In 99+% of cases, there is no registered IItemDecorator, so shaving off a couple of ns when rendering a GUI ItemStack makes sense in my opinion. Especially when it can be done so cheaply.

BTW: Carrying around a GlStateBackup for each item with a decorator instead of a ThreadLocal one seems overkill and wasteful, but it probably is inconsequential given the low number of items with decorators. Unless there are mods that decorate all items? Then it'd be worth changing. (But in that case, a way to register one decorator for all items would be even more sensible.)

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[Technici4n]

Can I see a before/after profile? ;)

[HenryLoenwind]

Can I see a before/after profile? ;)

I can set something up, but not today (11pm).

[embeddedt]

Couldn't this whole change be simplified to adding if (itemDecorators.isEmpty()) return; at the head of render? Much simpler than unfinalizing the class and adding an anonymous class, and should be just as fast. IMO that change could be merged even without profiling; it clearly makes sense.

[Technici4n]

Couldn't this whole change be simplified to adding if (itemDecorators.isEmpty()) return; at the head of render? Much simpler than unfinalizing the class and adding an anonymous class, and should be just as fast. IMO that change could be merged even without profiling; it clearly makes sense.

True. That is fine to do without a profile yeah. (But nonetheless I would like to know... is there any visible effect in any profile?)

[sciwhiz12]

This PR has Spotless violations. Please run spotlessApply to fix them.