I noticed that the (Chrome) browser on my laptop consumes considerable more power when I have the OGS start screen active, leading to a shorter battery life. You can see this if you go to the Windows Task Manager and look at the CPU percentages of the processes. Without the OGS start screen the CPU percentage of the browser is in the sub second range. With the OGS start screen it can go up to percentages in the order of 10%.
I take it that this is because the client will update the status of each game played at regular time intervals, probably in the order of once a second. If you only play correspondence games, the update frequency can be a lot lower, which I believe could limit CPU time. So I wonder if OGS takes this into consideration. Maybe it would be an idea to make the update frequency a parameter in the settings. Or even a choice between fast, medium and slow.
Does the same happen when you use list-view of the games? (it’s in preferences:
)
If not, then that’s a possible solution.
I like my correspondence games to update in more or less real time, I sometimes use the overview when there are multiple opponents online and we’re playing correspondence more or less in a live speed. A delay of a minute would make waiting quite boring on those occasions.
If you analyze network traffic, you’ll notice that OGS uses computationally-inexpensive websocket connections for transmitting game state, as opposed to HTTP polling. There are heartbeat pings, but these will not cause any noticeable increase in CPU or bandwidth utilization.
Rather, without spending a bunch of time delving into a performance profile of a game screen (or trying to interpret minified JS,) I suspect that the issue is related to how the board/timers/etc. being redrawn in the browser. These are often more computationally-intensive actions than any simple network traffic could hope to be.
