Fallback for no ARC, fix for #8166

[519q]

When no arc enabled metal backend leaks framedescriptor and buffers.
I guess proper way to solve this would be to activate arc, in cmake like this:

    set_source_files_properties(
        ${IMGUI_SRC_DIR}/imgui_impl_osx.mm
        ${IMGUI_SRC_DIR}/imgui_impl_metal.mm
        PROPERTIES COMPILE_FLAGS "-fobjc-arc"
    )

But in case there is no active ARC i added explicit destructor 

for framedescriptor and buffer caching.
This code is behind conditional if (__has_feature(objc_arc)),
so it works in both contexts adding robustness

also there is small shadowing issue in impl_OSX that would not let compile, 

removing type definition made it work.

Thanks!

[faridhassani95]

This PR looks solid and addresses two important issues:
1. Memory Leaks with Metal Backend:
The metal backend was leaking frame descriptors and buffers when ARC wasn’t enabled. The proper solution—activating ARC via CMake—is ideal for those environments. As you proposed, applying the following CMake command:

set_source_files_properties(
${IMGUI_SRC_DIR}/imgui_impl_osx.mm
${IMGUI_SRC_DIR}/imgui_impl_metal.mm
PROPERTIES COMPILE_FLAGS "-fobjc-arc"
)

ensures that ARC takes care of memory management automatically.

2.	Support for Non-ARC Environments:

In cases where ARC isn’t active, your addition of an explicit destructor for frame descriptor and buffer caching provides robustness. By conditionally compiling the explicit destructor using if (__has_feature(objc_arc)), the code now gracefully handles both ARC and non-ARC contexts.
3. Shadowing Issue in impl_OSX:
The small shadowing problem preventing compilation, which you fixed by removing the redundant type definition, cleans up the code and allows it to compile correctly.

Overall, your changes not only address the leak issue but also add a layer of robustness across different compilation environments. Thanks for the contribution—this should help prevent memory issues and improve overall stability on Metal backends.

[ocornut]

Thanks for your PR.

• You could ensure that all changes are following the local formatting style (brace position)?
• I haven't wrote the code but I am confused why the Metal layer isn't simply managing N buffers, where N is the number of frame in frame, generally 2-3, and grow existing buffer if it doesn't fit, instead of managing a general cache. Do you have an opinion on this?
• Why can't your change be implemented as part of the dequeueReusableBufferOfLength function?

Thank you.

[ocornut]

I have picked the OSX backend change as d3bb333 instead, simply removing the line and I'm not sure I understand why you didn't do that, since the event's modifierFlags has not changed?

[519q]

9ff64e1 here i fixed formatting.

i do not have an opinion on why there is cache and not couple reusable buffers. Also to my naive understanding purging all buffers on per second basis seems little erroneous, feels like every buffer should be timestamped so purge will happen only to old buffers, not to working correct ones(?)

as for why dequeueReusableBufferOfLength wont do this when no arc context i have no idea. It seems that it does same exact steps (among other things)- taking fitting buffer in use and removing it from cache. I tried to figure it out with googling and chatbots but had no luck. Some implicit rules.

in impl_OSX i just assumed intent and selected path of least change. There is no obvious reason for that line to be there.

Thanks

[ocornut]

You shoudn't be using chat bots but looking at the code and seeing if your change would make better sense inside dequeueReusableBufferOfLength().