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

Very long loading of the maximum "zoom out" level in 4K resolution #6566

Closed
DorpsGek opened this issue May 27, 2017 · 16 comments
Closed

Very long loading of the maximum "zoom out" level in 4K resolution #6566

DorpsGek opened this issue May 27, 2017 · 16 comments

Comments

@DorpsGek
Copy link

@DorpsGek DorpsGek commented May 27, 2017

Qwest8K opened the ticket and wrote:

I run OpenTTD (x64 version r27875, Windows 7 SP1) in 4K resolution (3840x2160). When i try choose maximum level of "zoom out", I get freeze of game. But forty seconds later game unfreeze with highest level of "zoom out". I immediatly did "zoom in" and again try opened largest view of area. Game freeze again, but successfully unfreeze twenty seconds later. I again did "zoom in" and maximum of "zoom out". It opened twenty seconds later. Again.

So, when game work in 4K (in FullHD all normal), it loading highest "zoom out" level with some time period. While switching between all the others levels of zoom in any direction (out-in, in-out) always instantaneous.

Also, loading of highest view depend on the size of map. Forty-twenty seconds - on 256x256 size. On 4096x4096 loading takes minutes.

Reported version: trunk
Operating system: Windows


This issue was imported from FlySpray: https://bugs.openttd.org/task/6566
@DorpsGek
Copy link
Author

@DorpsGek DorpsGek commented Jan 17, 2018

danielarmstrong wrote:

This bug is still in the latest version and it also happens on a windows 10 machine with an 2560 by 1440 monitor with super high specs.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6566#comment14833
@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Apr 11, 2018

I am not sure whether this is a bug, or works-as-intended. But we need to look into this to be sure :)

@Qwest8K
Copy link

@Qwest8K Qwest8K commented Apr 13, 2018

As author of this report, I start to wait.

@TrueBrain TrueBrain added bug and removed bug from FlySpray labels Apr 13, 2018
@planetmaker
Copy link
Contributor

@planetmaker planetmaker commented Jun 8, 2018

Sounds to me like an issue with the size of the visible map area.

Is the delay the same for different kind of maps, e.g. comparing a very busy one with many towns and vehicles (trains, road vehicles,...) and a "idylic" one with few villages and mostly country side?

My suspicion is: there's so many sprites to order, that it simply takes a load of time - longer than desirable.

@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Nov 1, 2018

I think this is fixed/improved with #6911.

@nielsmh nielsmh closed this Nov 1, 2018
@lediur
Copy link

@lediur lediur commented Oct 9, 2019

I don't think this is fixed - when zooming out to the maximum zoom level OpenTTD still freezes for 3-5 seconds for me. Running latest JGRPP 0.32-rc5.

@LordAro
Copy link
Member

@LordAro LordAro commented Oct 9, 2019

I would venture a guess that 3-5s is entirely expected - and a lot better than the originally reported 20-30s. 4k is a lot, and OTTD doesn't have any sort of GPU acceleration.

Please try with standard "vanilla" OTTD and give more information (map size, computer specs)

@lediur
Copy link

@lediur lediur commented Oct 9, 2019

Yeah it's definitely improved performance over the original report, but it's also still noticeable. With vanilla 1.9.2, it takes slightly longer ~5-7 seconds than JGRPP on an older version of the same map.

I've kinda worked around it in JGRPP by making sure to be in transparency mode (with invisible trees), which makes sense given the sprite rendering explanation from above.

Map size is 1024x1024, with lots of trees and towns e.g.
image. I think the trees are the render time killer since it takes <1s to render the largest zoom level with invisible trees, which is within the "tolerable to gameplay UI latency perception" threshold for me.

Specs:
Intel Core i7 4770K at 4.2 GHz
NVIDIA GeForce GTX 1080

Edit: after playing around with the transparency options, toggling building invisibility has a good <300ms latency, whereas toggling tree invisibility takes several seconds.

@LordAro
Copy link
Member

@LordAro LordAro commented Oct 9, 2019

I mean, there are a lot more trees than buildings... but it's possible (probable) there's some inefficiency somewhere that could be looked at

@james5922
Copy link

@james5922 james5922 commented Dec 25, 2019

Apologies for bumping a closed issue, but I'm also getting this on my 2k monitor. OTTD freezes for about 5 to 10 seconds when zooming out to the farthest zoom level. I'm using vanilla 1.10.0-beta2 and have an AMD Radeon video card... OS is Windows 7. Map size is 512x512.

@LordAro
Copy link
Member

@LordAro LordAro commented Dec 25, 2019

Alright then, let's reopen and see if anyone can reproduce anything significant

@LordAro LordAro reopened this Dec 25, 2019
@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Dec 25, 2019

The earlier referenced PR was reverted, I think. It broke sprite sorting in some edge cases, causing flickering and weirdness with some bridges and more. So performance should be back to what it was when this issue was first opened.

@Qwest8K
Copy link

@Qwest8K Qwest8K commented Dec 26, 2019

I reproduce situation of @james5922 in the same version (1.10.0-beta2), but in 3840x2160 resolution: map size 512x512, "5000" number of towns and "High" of industries, with trees and no water (rivers and seas) = constant ~10 sec. freeze when zooming out to the farthest zoom level.

@james5922
Copy link

@james5922 james5922 commented Dec 26, 2019

image
here were the worldgen settings for my map, if it helps

EDIT: Oh. Normally I play with transparent trees, so I decided to see what would happen if I turned on the "invisible" box for the trees - and the issue went away. As soon as I returned it to being transparent, the hang started right up again when I zoomed back out.

@ldpl
Copy link
Contributor

@ldpl ldpl commented Jan 25, 2020

PR #7962 should significantly improve this.

@JGRennison
Copy link
Contributor

@JGRennison JGRennison commented Feb 1, 2020

With reference to: https://github.com/OpenTTD/OpenTTD/blob/master/src/viewport.cpp#L1731
When the drawing area for a call to ViewportDrawChk exceeds 2097151 pixels (approx 1449 x 1449), at 8x zoom, the value of ScaleByZoom(bottom - top, vp->zoom) * ScaleByZoom(right - left, vp->zoom) no longer fits into a signed 32 bit integer. Signed overflow occurs, such that the value is considered negative, the branch is not taken, and no chunking of the drawing area occurs. This causes pathological performance issues in the sprite sorter in particular.
This can be corrected by use of int64 instead of int in the above comparison, and does not require any particular changes to the sprite sorter.

JGRennison added a commit to JGRennison/Upstream-OpenTTD that referenced this issue Feb 1, 2020
…hunking

This caused drawing areas larger than 2097151 pixels at 8x zoom to
not be subdivided into smaller chunks as required.
This resulted in pathological performance issues in the sprite sorter.
@nielsmh nielsmh closed this in 14af870 Feb 2, 2020
douiwby added a commit to douiwby/OpenTTD that referenced this issue Apr 16, 2020
…hunking

This caused drawing areas larger than 2097151 pixels at 8x zoom to
not be subdivided into smaller chunks as required.
This resulted in pathological performance issues in the sprite sorter.
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
10 participants
You can’t perform that action at this time.