FPS slowly drops when playing with stock screen open

Bug #1074655 reported by l p on 2012-11-03
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Medium
Unassigned

Bug Description

Started when I updated my about month old widelands trunk to bzr6439. Have not seen this before the update.

Steps to reproduce:
1. Load attached single player game on "No Friends". Set game speed to 3x or so.
2. Open stock screen showing wares in warehouses.
3. Play/wait for half an hour.
4. Frame rate starts to drop slowly. Mouse control becomes sluggish (for example when setting flags to road).
5. Close the stock screen. Game stalls for about 0.5 seconds and game runs smooth again.
To reproduce again, go to step 2.

Based on my tests, game speed does not affect to slowness, so you don't get this with 30x speed in 10 minutes.

Game is running windowed 2500x1500x32bit mode on 2.4GHz C2D with 6Gb memory, 64bit Ubuntu 12.04. Built as release.

l p (l-p) wrote :
Hans Joachim Desserud (hjd) wrote :

Welcome to Launchpad and thanks for reporting this issue.

After this was mentioned on IRC earlier today I played a game with r6439. Indeed there was a noticable slugginess when leaving the stock window open for longer periods of time. Closing it would revert the speed back to normal before it would eventually happen again as time passed.

Likely a regression triggered by the recent changes to ware numbers displayed in windows.

Changed in widelands:
milestone: none → build18-rc1
status: New → Confirmed
tags: added: regression ui
SirVer (sirver) on 2012-11-05
Changed in widelands:
importance: Undecided → Medium
assignee: nobody → SirVer (sirver)
SirVer (sirver) wrote :

So indeed the time is spent in the boost::signal call. it is too heavyweight for this use case.

SirVer (sirver) wrote :

So indeed the time is spent in the boost::signal call. it is too heavyweight for this use case. Ill investigate other solutions.

l p (l-p) wrote :

I wonder if boost::signal is really that slow, because when the window is opened, it does not slow things down (on my setup, at least). The slowness comes when the window has been opened for a while, which would indicate that something CPU-related leaks instead of signal being slow?

SirVer (sirver) wrote :

I do not know why boost::signal get slower with time, but I did profile the calls. so I am confident in my statement.

I implemented a simple observer pattern which fixes this problem in r6440.

Changed in widelands:
status: Confirmed → Fix Committed
assignee: SirVer (sirver) → nobody
l p (l-p) wrote :

Played 4hr game with bzr6440, did not see this happening anymore.

Thank you for fixing this!

SirVer (sirver) wrote :

My pleasure. That was a lot of fun to fix actually. It's cool when you can apply a simple pattern so easily and it falls into place so naturally.

_aD (ad-simplypeachy) wrote :

I'm seeing the same symptoms, but when a window of a production site is open (bakery, colosseum etc.). It takes several hours to trigger. I always play with the Message and Stock windows open, but found that when I closed them and left the production site window open, the game was still suffering from severe lag. Once the bug was triggered I could have the stock and message windows open and have no problem, but seconds after opening a production site window it would crawl to a halt again.

Once the production site window is closed the game usually reverts to its normal speed, and then when opened again it would lag. Saving and reloading the game restored normal operation until another few hours were played. I am not sure if the fact that I had the stock window open for several hours may have contributed to this bug so not sure if I should report a new bug or if this one needs re-opening.

SirVer (sirver) wrote :

I am fully confident that this is another bug and not the same. The underlying problem might be similar though. Mind opening a new bug and link to this here so you do no have to add the same description again.

SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers