Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Check Online Content" lags the UI #8024

Closed
TrueBrain opened this issue Feb 26, 2020 · 8 comments
Closed

"Check Online Content" lags the UI #8024

TrueBrain opened this issue Feb 26, 2020 · 8 comments

Comments

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Feb 26, 2020

Version of OpenTTD

1.10.0-RC1

Expected result

Opening "Check Online Content" works like any other window.

Actual result

Opening "Check Online Content" lags the crap out of the game. The title screen becomes sluggish, the mouse moves like it is on 2 FPS, etc.

Steps to reproduce

Open "Check Online Content"

More details

It seems that for every entry it adds to the list, it redraws the full UI. As the list is ~1300 entries long, and entries are being added one by one, this makes the UI become rather unresponsive.

An easy fix seems to be to not update the UI for every entry, as you cannot use the UI anyway during this time-of-lag.

@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Feb 26, 2020

Maybe set a timer (e.g. 250 ms) on the content window and check for a flag that gets set by the network receive code. Redraw if the flag is set.

@frosch123
Copy link
Member

@frosch123 frosch123 commented Feb 26, 2020

Mind that unoptimised builds spend a considerable amount of time on computing md5sums of savegames on your disk, to check which content you already have.

@TrueBrain
Copy link
Member Author

@TrueBrain TrueBrain commented Feb 26, 2020

Isn't that at boot? Anyway, the above problem also happens when there is only OpenGFX loaded.

@James103
Copy link
Contributor

@James103 James103 commented Feb 26, 2020

Mind that unoptimised builds spend a considerable amount of time on computing md5sums of savegames on your disk, to check which content you already have.

This means that pressing Check Online Content can cause lots of disk activity, which may result in minutes-long hangs on some hard drives. Is there any way to cache/skip this intensive verification step if on a hard drive?

@LordAro
Copy link
Member

@LordAro LordAro commented Feb 26, 2020

In no way should OTTD have to care about your storage medium

@spnda
Copy link
Contributor

@spnda spnda commented Feb 29, 2020

Both Debug and Release builds don't show ANY disk usage on my drives.
And I think the window in general lags the game quite a bit. I get 30-40ms draw times in that window even after all the data has returned from the server and has been drawn.

@James103
Copy link
Contributor

@James103 James103 commented Feb 29, 2020

@spnda Did you test this without having any scenarios or savegames installed, or did you test with the scenarios and savegames installed? Did it come up with no disk usage either way, or is it that the presence of the scenarios and savegames is what causes the "Check Online Content" to trigger some disk activity?

@spnda
Copy link
Contributor

@spnda spnda commented Feb 29, 2020

Did you test this without having any scenarios or savegames installed, or did you test with the scenarios and savegames installed?

I have 11 savegames installed and 2 scenarios.

Did it come up with no disk usage either way, or is it that the presence of the scenarios and savegames is what causes the "Check Online Content" to trigger some disk activity?

Not exactly sure what you mean. My C: and E: drives (C: for documents and E: for the installation) show 0-1% (most of the time 0%, the 1% might be from other programs running simultaneously) disk usage when checking for online content. When checking for missing content in save games and scenarios it runs as smooth as it should, no issues there.

Yexo added a commit to Yexo/OpenTTD that referenced this issue Jun 1, 2020
…ng content list

Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
Yexo added a commit to Yexo/OpenTTD that referenced this issue Jun 1, 2020
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
@Yexo Yexo closed this in a9b3312 Jun 1, 2020
LordAro added a commit to LordAro/OpenTTD that referenced this issue Jun 1, 2020
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
LordAro added a commit to LordAro/OpenTTD that referenced this issue Jun 1, 2020
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
LordAro added a commit that referenced this issue Jun 1, 2020
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
freprec added a commit to freprec/OpenTTD that referenced this issue Jun 19, 2020
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.

Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.