[FIXED] [bug] [player] Pause slows the drawing

[Simon]

We discussed this in #nl yesterday.

Chat summary: The game scrolls slower during pause. This is dubious: During play, we update physics and draw, but during pause, we only draw. Pause cannot possibly run slower than play, because it's strictly less work -- unless there is a bug.

namida has suspected that the game renders the level twice during pause.

Source code: In v1.47, GameWindow.pas:247, procedure TGameWindow.DoDraw; seems responsibe to render everything. This tells gadgets, lemmings, and the terrain to draw themselves.

When I grep the codebase for DoDraw, I find 7 calls to this method, spread across GameWindow. With so many calls all over the place, I didn't try to reason whether DoDraw gets called too often.

One solution is to make DoDraw do nothing but set a flag. When all input and physics are done, and the flag is set, draw. You already have fNeedRedraw, but aren't using it consistently for this.

-- Simon

[namida]

The primary call to DoDraw is after a call to Game.UpdateLemmings (assuming hyperspeed (ie: frameskips of more than 1 frame) isn't active).

The reason for the other updates is in cases where a redraw is needed, but a physics update does not occur; eg. after scrolling, when a new lemming is moused over, etc.

I don't remember off-hand how fNeedRedraw works, or if it's even made much use of at all. I do vaguely recall implementing it, but it's possible I'm not remembering correctly here and it's part of Nepster's code.

More intelligent detection of whether a redraw is actually needed (vs. a situation of a type that may need it, but in this case doesn't; eg, you have clicked the minimap but the resulting scroll position is exactly where you already are) is probably the best way about this.

[Simon]

IRC 2016-10-03:

[16:50:49]    <mobius_> NL is using about 20 CPU that doesn't seem right..
[16:51:26]    <mobius_> I don't remember it being that heavy
[17:09:31]    <Nepster> namida42: mobius_ is correct: For some reason NL uses 20% CPU when paused, but much less when non-paused.

-- Simon

[mobius]

I kind of doubt it has anything to do with this but it may be a related issue. [I'm using 1.47n-D]

Some packs cause the game load slower than others. I remember packs in older versions loaded very quickly.
Playing BulletRide's pack with the latest version loads a tad bit slower. When I tried to play Flopsy/Wafflems pack it loads very slowly and sometimes crashes during loading. (there is no crash message just windows "NL stopped responding"
Please note that this happens when I try to play the first level which is dirt and there doesn't seem to be anything unusual about it. Also; the start-up of the program itself is slower. This is when I noticed the CPU issue.

[Nepster]

This is indeed unrelated: The pausing issue occurs as well in the experimental new-style-formats version, while it loads levels even faster than V1.43 (at least on my computer).
And to be honest: As we will at some point (hopefully in the near future) switch to the new-style-formats version, I don't see much reasons to invest a lot of work into speeding up the loading time in V1.47/V1.48.

[namida]

I attempted to find what might be causing this, to limited avail.

Replacing TGameWindow.DoDraw with a "null" function reduced the unpaused-paused gap in CPU usage somewhat; but CPU usage when paused is still significantly higher than when unpaused, meaning TGameWindow.DoDraw (or unnessecary calls to that) are at most partly responsible, possibly not even at all.

With that being said, changes to fix the weird windowing system would require significant parts of TGameWindow to be rewritten anyway. As such, it's probably not too worthwhile trying to find the issue in the current code.

[Nepster]

This is fixed in the next NL version by less frequent unnecessary updates of the game screen. However I am not sure whether I caught all exceptional use-cases while testing my changes. So please report any cases where the level image should change, but the old image is still displayed.