Game Performance Degradation Over Time

[TKanX]

Description:

The game experiences significant performance issues during gameplay. Initially, the game runs smoothly, but after approximately the 10th turn, it begins to lag and eventually becomes unresponsive. The memory usage remains stable at around 100MB, so memory leakage is not suspected. The issue seems to be related to the rendering logic using the Canvas API.

Steps to Reproduce:

1. Start a new game session.
2. Play through approximately 10 turns.
3. Observe the increasing lag and eventual freezing of the game.

Expected Behavior:

The game should maintain consistent performance throughout all turns, without noticeable lag or freezing.

Actual Behavior:

Performance deteriorates after several turns, leading to significant lag and eventual page unresponsiveness.

Possible Causes:

• Inefficient or excessive Canvas redraws.
• Accumulation of event listeners or timers.
• Object creation without proper cleanup or reuse.
• Other potential causes related to rendering optimization.

[TKanX]

Performance Recording Completed

I have completed a performance recording to analyze the issues with game performance. The recording includes details on where the performance degrades and potential bottlenecks.

Timeline Spikes: Look for any sudden spikes in activity on the timeline that might indicate performance issues. Frame Rate: Check the frame rate graph to see if there are significant drops. Main Thread Analysis: Review the main thread’s activities to identify any long tasks or inefficient operations. Rendering Issues: Analyze the rendering section for frequent or excessive painting operations. Memory Usage: Observe memory usage patterns to ensure there are no unexpected increases.

@tedhyu

[tedhyu]

Very impressive, Tony.

[TKanX]

Performance Analysis Update

I have recorded the performance data during the occurrence of the lagging issue. Here’s a summary of my findings:

Upon examining the first critical time frame where the game begins to experience severe lag, the following key observations were made:

1. Frame Rate Drop and Freeze:

The frame rate starts to drop sharply just before the game completely freezes. At this point, the frame rate data disappears from the timeline, indicating a total halt in the rendering process.

Normal frame rate:

Drop frame rate:

2. GPU Activity:

Multiple GPU tasks, each taking approximately 751ms, were identified during the problematic frame. The green blocks on the timeline represent these GPU operations, indicating that the GPU was heavily engaged in rendering or compositing tasks during this period.

Upon examining the fourth critical time frame the task lasted for 13.77 seconds, leading to a substantial lag and eventual freezing of the application. The detailed analysis of this task reveals insights into its origin and impact:

Detailed Analysis of Long JavaScript Task:

1. Long Task Summary:

• Warning: Long task took 13.77 s.
• Total Time: 13.77 s
• Self Time: 9.41 ms

2. Event Level:

• Event Type: click
• Total Time: 13.76 s
• Self Time: 60 μs
• Aggregated Time:
  • Scripting (self): 0 ms
  • Scripting (children): 13,454 ms
  • System: 306 ms
  • Total: 13,760 ms

The long task was triggered by a click event, consuming a substantial amount of time in scripting, specifically within its children functions.

3. Function Call Level:

• Function: (anonymous) @ game.js:676:46
• Total Time: 13.76 s
• Self Time: 14 μs
• Aggregated Time:
  • Scripting (self): 0 ms
  • Scripting (children): 13,454 ms
  • System: 306 ms
  • Total: 13,760 ms

The function at game.js:676:46 was responsible for the majority of the time, indicating that it contains the core logic causing the delay.

4. hideAvailablePositions Function:

• Function: hideAvailablePositions @ game.js:1255:25
• Total Time: 13.76 s
• Self Time: 0 ms
• Aggregated Time:
  • Scripting (children): 13,453 ms
  • System: 305 ms
  • Total: 13,759 ms

This function, hideAvailablePositions, primarily contributed to the delay by delegating extensive tasks to its child functions.

5. _restorePieces Function:

• Function: _restorePieces @ game.js:1119:17
• Total Time: 13.76 s
• Self Time: 85.21 ms
• Aggregated Time:
  • Scripting (self): 85 ms
  • Scripting (children): 13,368 ms
  • System: 305 ms
  • Total: 13,759 ms

The _restorePieces function, which handles significant processing, was one of the major contributors to the task's total execution time.

6. drawPiece Function:

• Function: drawPiece @ game.js:1170:12
• Total Time: 383.74 ms
• Self Time: 3.72 ms
• Aggregated Time:
  • Scripting (self): 4 ms
  • Scripting (children): 379 ms
  • System: 1 ms
  • Total: 384 ms

The drawPiece function, while not the main contributor, still took a significant amount of time due to processing of drawing operations.

7. restore Function:

• Function: restore
• Total Time: 362.65 ms
• Self Time: 362.65 ms

The restore function was responsible for a substantial amount of the time, suggesting it is a critical point of performance issues.

8. CPP GC (Garbage Collection):

• Total Time: 31 μs
• Self Time: 1 μs

Garbage Collection (GC) in C++ had minimal impact compared to the JavaScript tasks, indicating that the primary performance issues are related to the JavaScript execution.

The long JavaScript task that caused the game to freeze for 13.77 seconds was primarily due to extensive processing within functions like hideAvailablePositions, _restorePieces, and drawPiece. The performance issue appears to be rooted in inefficient handling of rendering and state management tasks.

Key Findings:

• hideAvailablePositions Function: This function consistently appeared as a major contributor to the lag. It triggers extensive processing and delegations to other functions, resulting in high execution times.
• _restorePieces Function: This function is involved in substantial processing and is a key factor in the observed long task durations. Its inefficiencies have a direct impact on performance.
• drawPiece Function: Although not the primary cause, this function contributes to the rendering delays. The time spent in drawing operations adds up to the overall lag.

@tedhyu

[TKanX]

Optimized piece rendering and caching

https://github.com/tridecco/game-client-web/commit/16aed06d935f13b4f4d66df283efa8b7f67c9a64

• Refactored _restorePieces to optionally use a cache (piecesCanvas) for improved performance.
• Updated resizeCanvas to handle resizing of piecesCanvas and call _restorePieces with caching disabled for initial rendering.
• Modified drawPiece to draw pieces on piecesCanvas first, then copy to the main canvas, reducing the need for frequent redraws.

Changes:

• Added useCache parameter to _restorePieces method for conditional caching.
• Introduced piecesCanvas and piecesCtx for optimized piece rendering.
• Adjusted drawPiece method to use caching canvas before drawing on the main canvas.

[TKanX]

Performance and rendering issues have been successfully resolved. After optimizing the piece rendering process and introducing a caching mechanism, the performance has significantly improved. I re-recorded the performance metrics, and there are no more signs of lag or unresponsiveness. The memory usage is now between 25-40 MB.

@tedhyu