ways to reduce superflous cpu usage? about dear-imgui.hs

[dpwiz]

Check if it has ridiculous amount of FPS. Looks like you have vsync disabled or something.

I just checked the vulkan demo and it uses MAILBOX presentation for no good reason.

[cartazio]

So guard the rendering part of the interaction loop with a timer constraint? I’m not doing game physics, I just don’t want to do renders unless there’s been data changes. I’ll play around with the mvar/tvar stuff I was thinking of doing. Or am I missing something?

…

On Mon, Sep 4, 2023 at 8:27 AM Ollie Charles ***@***.***> wrote: The suggest best practice is to fix your timestep <https://www.gafferongames.com/post/fix_your_timestep/> — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQXIBQSELN6FBTGSZQDXYXCLFANCNFSM6AAAAAA4JPDGLU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ocharles]

@cartazio I actually removed that comment as it's really more about predictable physics. But in general, you don't really want to render as fast as possible. It's more typical to use something like VSync to synchronise your loop to the monitor's refresh rate, or to simply cap FPS artificially.

[cartazio]

Yes. I know. I’m asking about what software patterns people use to make the render thread take steps only when there’s some work to be done.

…

On Mon, Sep 4, 2023 at 12:29 PM Ollie Charles ***@***.***> wrote: @cartazio <https://github.com/cartazio> I actually removed that comment as it's really more about predictable physics. But in general, you don't really want to render as fast as possible. It's more typical to use something like VSync to synchronise your loop to the monitor's refresh rate, or to simply cap FPS artificially. — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQWZSKYKQR4FRLFC3JLXYX6WZANCNFSM6AAAAAA4JPDGLU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cartazio]

I’m currently doing stuff with explicit thread delay 10ms , but that’s less than ideal. I believe there may be a more work optimal strategy using mvars or stm data structures. On Mon, Sep 4, 2023 at 3:13 PM Carter Schonwald ***@***.***> wrote:

…

Yes. I know. I’m asking about what software patterns people use to make the render thread take steps only when there’s some work to be done. On Mon, Sep 4, 2023 at 12:29 PM Ollie Charles ***@***.***> wrote: > @cartazio <https://github.com/cartazio> I actually removed that comment > as it's really more about predictable physics. But in general, you don't > really want to render as fast as possible. It's more typical to use > something like VSync to synchronise your loop to the monitor's refresh > rate, or to simply cap FPS artificially. > > — > Reply to this email directly, view it on GitHub > <#187 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAABBQWZSKYKQR4FRLFC3JLXYX6WZANCNFSM6AAAAAA4JPDGLU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[dpwiz]

dirty :: MVar () should be enough for SDL.

But dear-imgui, being an immediate mode gui, requires a constant rate of ticks/updates since it handles its input in the moment.

Maybe I'm wrong on this. Try setting your delay to 10 seconds instead and see if UI still works. If it is, then you can employ that flag var.

[cartazio]

I’ll have a look, my fuzzy understanding is that dearimgui While having an immediate mode api, actually does a diff for determining what to change each time you do

…

On Tue, Sep 5, 2023 at 1:25 AM Alexander Bondarenko < ***@***.***> wrote: dirty :: MVar () should be enough for SDL. But dear-imgui, being an immediate mode gui, requires a constant rate of ticks/updates since it handles its input in the moment. Maybe I'm wrong on this. Try setting your delay to 10 seconds instead and see if UI still works. If it is, then you can employ that flag var. — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQQFPTZNAKMH6F4MRJLXY3OV5ANCNFSM6AAAAAA4JPDGLU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cartazio]

so definitely doesn't update the gui until the next draw call, so 100ms is probably the slowest thats tolerable

[dpwiz]

You can make window events flip a "dirty" flag that would trigger a new frame, maybe with a small debounce to prevent burning CPU on every pixel a cursor had traveled.

[cartazio]

Yeah I see now , I’d have a thread used the sdl2 event apis

…

On Mon, Sep 11, 2023 at 1:32 PM Alexander Bondarenko < ***@***.***> wrote: You can make window events flip a "dirty" flag that would trigger a new frame, maybe with a small debounce <https://hackage.haskell.org/package/auto-update-0.1.6/docs/Control-Debounce.html> to prevent burning CPU on every pixel a cursor had traveled. — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQS7SQ4POL23A4KTHX3XZ5DJTANCNFSM6AAAAAA4JPDGLU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[YellowOnion]

A quick option is to just grab the display mode and convert that to a thread delay.

[dpwiz]

Anyway... I don't think dear-imgui can do something here as frame rate is governed by a presentation/windowing framework, picked and configured by user.

[ad-si]

@cartazio Did you find a good software pattern?

[cartazio]

I think i chose a delay corresponding with 60fps. For a more complex application I’d have application logic and gui code/render loop in distinct threads and have some timer based loop for render calls

…

On Sat, Nov 18, 2023 at 2:45 PM Adrian Sieber ***@***.***> wrote: @cartazio <https://github.com/cartazio> Did you find a good software pattern? — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQWKSLKH5UHR4IAT5BTYFEF6LAVCNFSM6AAAAAA4JPDGLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGYYDQMJRGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>