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

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

As author of this report, I start to wait.

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.

I think this is fixed/improved with #6911.

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.

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)

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.
. 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.

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

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.

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

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.

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.

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.

PR #7962 should significantly improve this.

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.