Can someone give me a cargodist save with lots of stations and connections?

[btzy1996]

I'm trying to get an estimate of how slow it is to redraw the "cargo flow legend" overlay in the game, in the hope of modifying the GUI so that the delay when redrawing the overlay (after panning or zooming) isn't so apparent. Can someone give me a really large cargodist save (the more stations and connections (i.e. edges between two stations) the better)?

[mrjack2]

778 stations, cargodist on all cargos. Needs JGR patchpack.

[JGR]

I should point out that linkgraph recalculation and details of how the graphical overlay is implemented differ significantly between trunk and that patchpack.
It already includes solutions to resolve the issue of the cargodest overlay not updating in a timely manner when being scrolled.
Using a JGR patchpack savegame/version will probably not give you the correct results for modifying trunk.

The delay isn't caused by how long it takes to actually do the rendering and isn't related to how many nodes/links are on-screen,

For trunk savegames, try some of these: https://wiki.openttdcoop.org/PublicServ ... ll_of_Fame

[btzy1996]

Thanks for the save.

The delay isn't caused by how long it takes to actually do the rendering and isn't related to how many nodes/links are on-screen

From what I think the code is doing, it seems that someone realised iterating through all stations and edges is too slow to be done on every single tick, so (to prevent choppy scrolling/resizing) the delay is added to make OpenTTD only need to rebuild the cache once, at the end of the scroll/resize. It won't be related to the number of nodes/links on screen, but amount of work for rebuilding the cache is proportional to the number of nodes/links in total on the whole map. Am I correct?

[JGR]

From what I think the code is doing, it seems that someone realised iterating through all stations and edges is too slow to be done on every single tick, so (to prevent choppy scrolling/resizing) the delay is added to make OpenTTD only need to rebuild the cache once, at the end of the scroll/resize. It won't be related to the number of nodes/links on screen, but amount of work for rebuilding the cache is proportional to the number of nodes/links in total on the whole map. Am I correct?

That is pretty much the case, plus the cache is re-calculated periodically.
The details of how the delay is determined/handled have been changed recently.
Resizing without scrolling (for the main viewport at least) doesn't trigger a sooner cache rebuild, so the display is only updated after the next periodic update.

For reference some of the things which I've already done in this area are:

* For the smallmap: just cache the whole graph, most of it will be visible anyway
* For viewports: incrementally update the existing cache as necessary during scrolling or zooming, and cache a slightly larger area than the viewport area to give some margin
* Cache more node and edge details to avoid needing to recalculate them during drawing
* Better line visibility/clipping algorithm (for whether lines intersect the drawing area and should be cached and/or drawn)
* Some general improvements to the cache performance

They're in this repo: https://github.com/JGRennison/OpenTTD-patches

[btzy1996]

Thanks for the information! I'll be sure to check the code in your patch pack