TileMap editor is slow with large tilemaps

[grusad]

Godot version

4.0 beta 16

System information

Linux Min 19

Issue description

Currently developing a 2d open world game and have encountered problems using Tilemaps.
When editing a large map the editor lags, freezes and crashes all the time. Its completly unsuable.

Running the game workd flawless, but the problem occurs when editing the level in editor.

Is the tilemap editor not supposed to be able to edit large maps?

Steps to reproduce

edit:
Create a tilemap with 800 x 800 tiles.

Minimal reproduction project

minimal.zip

[grusad]

I can add on to this that editing tile data, creating animation, selecting and deselecting tiles gives the same lag, freezes and crashes.

[joemicmc]

I've spotted the same. Overtime tilemap editor performance tanks. Reloading project seems to be okay though and works fine. Possibly not freeing some objects somewhere? I'm on latest Godot 4.0 and using a tilemap with 64x64 cells.

Edit: Seems to be when you use the flood fill. After filling an area the performance gets pretty awful, but reloading scene sorts it out.

[Al-p-i]

Hey!
I probably have the same problem.
The TileSet window within Godot editor is freezing and lagging a lot when I open a big TileSet (like this one).
Any action within the window is freezing (select/erase/scroll) to the point that it is absolutely unusable.
Though I am not sure if TileMap and TileSet considered the same window or this is a separate issue.

v4.0.3.stable.official [5222a99]
macOS 13.4.1 (22F82)

[anonomity]

I have the same problem, I have about 175,000 terrain tiles, and it was lagging when I was editing the terrain bitmask or editing the tile properties, but not when I was erasing or placing terrain tiles. The way I work around this issue is I save the tileset as a .tres file and then open a new scene and create a new tilemap, place the saved tileset .tres file and then when I edit the tileset in the new scene automatically saves the properties in my large world and I'm able to edit it at normal speed.

[dandeliondino]

I can confirm this in 4.0, 4.1 and 4.2-dev3, specifically related to the situation in the last comment.

I've run into this lag when using my plugin TileBitTools. The plugin retrieves and edits TileData (terrain set, terrain and peering bit values) for multiple tiles at a time. After it makes the edits, if there are tiles painted on the tilemap, there is up to a few seconds of lag that appears to be directly related to the number of cells that have tiles. If there are no cells with tiles, there is no lag at all. It does not matter whether the TileData belongs to tiles that are painted on the TileMap. Even if the edits are only to TileData objects for tiles that are not currently painted on the TileMap, the lag occurs. It also does not matter how many TileData objects are edited at once. I have tried manually changing a single terrain value for one tile, and it still causes the lag. I also get the same lag when changing other values not related to terrain.

I am unable to capture this lag in line-by-line profiling in GDScript. Setting and retrieving TileData properties do not appear to be the direct cause of the slowdown, since they take the same time to complete regardless of whether there are tiles on the TileMap. This seems to point to the TileMap responding to the TileData being changed, and possibly performing some updates on each occupied cell, regardless of whether its TileData is changed or not.

[dandeliondino]

An update to my above comment. It looks like the linked PR #74603 was intended to limit updates to cells that are "dirty", which should address this problem. It appears to be superseded by #81070. I just tried the build artifact from that PR, but I'm still getting the same lag. This happens when there are many tiles on the TileMap, and I edit a TileData property for a tile that is not currently placed on the TileMap. It is difficult to say whether it is less lag than prior as I'm not using a setup with C++ profiling, but, subjectively, it is still a noticeable editor freeze.

[crei0]

I've tested on a topdown game I'm developing, by running on v4.1.1 and on v4.2.dev5

Note: My game has no optimizations... I probably should divide the tilemap into multiple tilemaps and then I should use something like VisibleOnScreenEnabler2D to try to hide and show the tilemaps that are visible

Screenshot of comparison below:

I'm using:

Vulkan (Forward+)

V-Sync disabled 

Operating System: Pop!_OS 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 6.4.6-76060406-generic (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600 6-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD Radeon RX 6750 XT

The (main) tilemap I'm using is:

Tilemap information

Number of tiles by layer:
layer1 | 8
layer2 |2052
layer3 |1818
layer4 |37290

Total number of tiles (all layers):
41168

(tiles number calculated using VS Code on the tilemap data)

Cell quadrant size = 16px

[Al-p-i]

I was able to debug my case a little bit and it seems to be a separate issue.
In my case the Atlas View is lagging when moving the mouse over the large TileSet in the TileSet panel:

The reason is - every 'draw' cycle the grid is re-drawing all it's rectangles, so it's quadratic of the size of TileSet.

Profiling shows that adding and removing the rectangles eats all the CPU

Disabling the grid redraw here completely solves the lag.

So the 2 ways that I see to fix this are:

• redraw TileSet panel including the grid in a more lazy manner instead of on every 'draw' signal
• or make a grid of lines, not rectangles (and so it's linear of the size of TileSet)

Though I am new to Godot, so I welcome any ideas on how that should better be fixed :)