Expose CFRunLoopTimerCreate interval as setting for iOS

[Braymatter]

Description

Expose the EventLoopWaker interval as a configurable setting for the ios platform:

IOS Bevy apps are using a lot of CPU resources by default because this interval is so short. We've had positive impact on CPU/Energy use by lowering it to around 200hz instead of 1Mhz in a private fork. Ideally this setting would be exposed to client applications as realtime apps may have different polling requirements than input reactive apps etc.

Related to #3906, #3816

Relevant platforms

iOS

[madsmtm]

Thanks for the suggestion! The timer is intended to be internal, and it's "just" a bug that it's triggering so frequently, so I'm not gonna expose a knob for tuning this (instead, we should fix the underlying bug).

[Braymatter]

The bug's been in limbo for some time -- Is there anything I can do to support getting the fix merged in?

[madsmtm]

I guess test #3906, but really what's needed is understanding of why the bug triggers in the first place

[VladasZ]

Hi @madsmtm . So the only way to make it work properly today is to use a fork with different timer interval?

[madsmtm]

Until someone does the work to fix the bug properly, then yes. Which, realistically, will have to be me, but could technically be someone else.

[madsmtm]

My reasoning why I don't just merge #3906 and call it good is that I fear that it might break something else, and because I feel that's just not the way to do software development.

But writing that down, I guess iOS is very broken right now anyhow, so I retract my previous strong wording, I'm not that adamant about it. I'm still against changing a timer interval (that just masks the problem), but if you've really tested and think that my PR fixes it, then we can merge it without understanding of why it fixes it.

[extrawurst]

@Braymatter and whoever else stumbles on this, there is capable workarounds to this timer: configure WinitSettings in Bevy. there is a post about this too.

[VladasZ]

@madsmtm I tested patch from #3906 in my project and it definitely fixed my issue:

Before:

After:

I fear that it might break something else, and because I feel that's just not the way to do software development.

That is a good intention and I would agree with you in any other situation. But winit on iOS is currently unusable because of this bug and drains battery of mobile devices like crazy. In my opinion it is better to have at least some kind of fix for that than have no fix at all. If some other issues will happen because of this fix then somebody will create another issue and maybe it will help us understand this problem better.

[extrawurst]

@VladasZ is this using winit in the context of a bevy app?

[VladasZ]

@extrawurst no it is my own project. You can see all the code in my issue: #3816 . The only dependency is winit.

[Braymatter]

@extrawurst I appreciate you linking your blog post, we've also used WinitSettings successfully in our project. I think this Timer issue is maybe slightly different though. I still see differences in CPU profiling when I modify the timer frequency.

@madsmtm
I get your viewpoint about not wanting to expose the timer polling frequency, but given that iOS is (to everyone's point) functionally unusable without the fix I think it would be good to get it tested and merged rather than it's current limbo state.

I can try and pull your fix in and see if it causes any issues in our bevy app.