New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.18.x] Allow safely registering RenderType predicates at any time #8671
[1.18.x] Allow safely registering RenderType predicates at any time #8671
Conversation
patches/minecraft/net/minecraft/client/renderer/ItemBlockRenderTypes.java.patch
Outdated
Show resolved
Hide resolved
patches/minecraft/net/minecraft/client/renderer/ItemBlockRenderTypes.java.patch
Outdated
Show resolved
Hide resolved
patches/minecraft/net/minecraft/client/renderer/ItemBlockRenderTypes.java.patch
Outdated
Show resolved
Hide resolved
+ } | ||
+ | ||
+ | ||
+ public static Map<net.minecraftforge.registries.IRegistryDelegate<Fluid>, java.util.function.Predicate<RenderType>> getFluidLayerPredicatesView() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these view methods necessary? The map being wrapped is already a copy, creating an unmodifiable instance seems like unnecessary overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These methods only provide a view to prevent callers from modifying the map that may be concurrently accessed by the rendering process.
patches/minecraft/net/minecraft/client/renderer/ItemBlockRenderTypes.java.patch
Outdated
Show resolved
Hide resolved
This looks completely fine to me, but I will leave it to another team member to merge, as I am too close to the issue and a bit out of the loop in general. |
…inecraftForge#8671) * Allow safely registering RenderType predicates at any time * Requested changes
This PR effectively supersedes #8664 by providing a solution that keeps the performance benefit of the initial change in #8476 while avoiding breaking mods that need access to the predicate map, such as CTM.
This is done by using a lazy "copy-on-write" implementation where the map is only actually copied on the first read access after modification.
The PR also adds getters to allow mods like CTM to access an unmodifiable view of the maps instead of accessing internals via reflection.
Quote of the description of #8664 for completeness: