Only re-render if the model has changed

[z0w0]

During the development of Helm 1.0, the sample mechanics introduced in previous versions (which prevented excess rendering) was removed. To optimize rendering, the render function should be changed to require an Eq implementation on the engine user's model type and then check the model is not the same before rendering.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[z0w0]

This was done by simply marking the model as dirty when the game model is changed by an action, and then this dirty flag is turned off after being rendered. Better than requiring an Eq constraint.

[kasbah]

I don't think you have solved this unfortunately, both the flappy and the restored hello example peg one CPU core at 100% while idle.

[z0w0]

Hmm. I'll investigate this weekend. Happy if someone beats me to it :)

[kasbah]

It may not be re-rendering but polling for events in a really tight loop. I did some profiling with the hello example:

stack install --profile
stack exec -- ghc -prof -fprof-auto -rtsopts examples/hello/Main.hs
examples/hello/Main

Which gives a Main.prof file:

	Wed Jun 28 15:08 2017 Time and Allocation Profiling Report  (Final)

	   Main +RTS -p -RTS

	total time  =        3.29 secs   (3293 ticks @ 1000 us, 1 processor)
	total alloc = 938,042,536 bytes  (excludes profiling overheads)

COST CENTRE            MODULE                 SRC                                             %time %alloc

tick                   Helm.Engine.SDL.Engine src/Helm/Engine/SDL/Engine.hs:(129,3)-(141,37)   35.0    1.2
pollEvent.\            SDL.Event              src/SDL/Event.hs:(679,37)-(683,43)               24.0    0.0
superstep.loop         FRP.Elerea.Param       FRP/Elerea/Param.hs:(167,5)-(176,64)             19.0   53.4
step                   Helm                   src/Helm.hs:(67,1)-(85,65)                        5.2    8.7
externalMulti.\.sample FRP.Elerea.Param       FRP/Elerea/Param.hs:469:18-89                     2.7    8.7
start.\                FRP.Elerea.Param       FRP/Elerea/Param.hs:(156,22)-(160,14)             2.4    0.0
pollEvent              SDL.Event              src/SDL/Event.hs:(679,1)-(683,43)                 2.4    9.9
initialize             SDL.Init               src/SDL/Init.hs:(61,1)-(63,39)                    1.5    0.0
superstep              FRP.Elerea.Param       FRP/Elerea/Param.hs:(164,1)-(176,64)              1.4    3.1
moves                  Helm.Mouse             src/Helm/Mouse.hs:(23,1)-(26,42)                  1.1    2.5
start                  FRP.Elerea.Param       FRP/Elerea/Param.hs:(152,1)-(160,14)              1.1    3.1
superstep.deref        FRP.Elerea.Param       FRP/Elerea/Param.hs:166:5-53                      0.4    3.1
addSignal.fin.\        FRP.Elerea.Param       FRP/Elerea/Param.hs:(190,37)-(192,56)             0.2    3.1
externalMulti.\        FRP.Elerea.Param       FRP/Elerea/Param.hs:(467,27)-(470,69)             0.1    1.2
memoise                FRP.Elerea.Param       FRP/Elerea/Param.hs:265:1-64                      0.1    1.9

[z0w0]

I'd thought that the SDL pollEvent wouldn't be intensive.
What exactly are the possible solutions to this?
Should there be a thread delay, perhaps?

[kasbah]

I think the solution is to use a blocking read with a timeout, i.e. <https://hackage.haskell.org/package/sdl2-2.1.0/docs/SDL-Event.html#v:waitEventTimeout> The timeout could be something like 1ms if rendering can cope with that delay. If rendering isn't dependent on the event read completing we could even use a completely blocking read (waitEvent). ​

[z0w0]

Based off the documentation for SDL.Time.Event, I'm inclined to believe we shouldn't be using any SDL2 API wait implementations but instead should just block the thread using GHC's threadDelay (especially since the game loop is on the Haskell end). I think adding two new game configuration options (with sane defaults) will suffice: updateLimit a millisecond unit delay for sleeping the thread (I think 1ms would be a fine default) and fpsLimit a soft-limit to the FPS the game should render frames at

There might be games where input lag is acceptable for the gain of minimised CPU usage, so the dev may opt to increase the updateLimit.

[kasbah]

Yeah, I think you are right about that although it's not explicitly documented.

[z0w0]

Been under the weather and haven't had a chance to look at this yet and am going on holidays for a week tomorrow. Happy to Paypal $10 AUD through to any legend that fixes this before I get back :)

In particular:

• Add the soft-limit to the rendering rate as two enum variants, data FPSLimit = Unlimited | Limited Int (defaults to 120FPS)
• Add the hard-limit to the engine tick with threadDelay as two enum variants like the above, data UpdateLimit = Unlimited | Limited Double where the unit here is either milliseconds or microseconds (threadDelay takes microseconds IIRC)

These two should both go on the SDL engine config, or game config. Both would work, but game config might be more appropriate because those two settings won't be specific to the SDL engine.

P.S. I realised two other things related to this issue:

• It's only polling one event every engine tick - it should be polling all of the events available in a single tick otherwise it pumps the game actions out of the subscriptions slowly every tick, and commands get run much more than they should..
• Exposed events aren't re-rendering the engine

[nikita-leonov]

This one is somehow connected to #118. I implemented FPSLimit Limited and flickering disappeared. I am not proud by an implementation yet as it was POC, so I may hold it for a little, but as soon as it will be done I will provide a PR. I plan to deliver it in two separate PRs. One for FPSLimit and another one for UpdateLimit. Issues mentioned at very bottom of previous comment will require a separate attention as well.